Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Lessons from the Beach

Here are Pivotal we call our time between billable projects “the beach.” We spend most of this time working on projects which are internal or open source, sometimes both. One such project is Project Monitor and on my last go-round on the beach I got to work on it with my long-time colleague Mr. Saracco.

Project Monitor is a quick way for a team to see the status of their test suite. It’s basically a board of tiles, one for each test suite, colored either green or red depending on the current state of the build. It’s an interesting app to work on because it’s used in every Pivotal office and it’s part of our daily lives. It’s fun and it feels rewarding to work on something you see out of the corner of your eye every day. It’s also a little nerve-wracking. If you break something, every one of your co-workers knows!


Project Monitor has historically been a bit of a tangle. Frequently, a Pivot or two has a week or less on the beach and they’re tasked with implementing some new feature or fixing a bug and then they’re off on another project. Digging through the codebase, you can see there’s some baggage. Maybe there’s a beloved tool from a previous project, a half-used framework, or a–ahem–clever use of code. Not always, but sometimes, these things trip up the next developer.

A fundamental truth about code is that it has more than one audience. We often think of the compiler or the interpreter as the end consumer of our code, and of course that’s true. But it’s easy to downplay how important it is to think about the next set of eyes on your codebase. Even if you have no collaborators and develop your software in a sound-proof bunk, you have in the very least your future self to communicate with.

My biggest lesson from this go-round on the beach is that it is exceptionally important for open source software to code in such a way that optimizes for quick developer ramp up. This means writing code where intent is clear. It means minimizing dependencies so as to shrink the number of necessary technologies for a developer to additionally ramp up on. It means nice, clean commits with clear logs. In short, it means having a boatload of empathy for the next person reading the code.


On a private project with a small, tight team, there’s plenty of leeway. Someone with some history can just explain code that a new dev finds confusing. There is usually no such luxury on open source projects. Furthermore, the lifetime success of your project may be determined by willing members of the community standing up and pitching in. The next person to look at your code may not have any context at all. They will wake up, Memento style, and only see the code at hand. They do not have the history you do.

When you’re doing open source work, lease, please, please think of the next developer when you reach for that shiny new gem, that clever piece of meta-programming, that half-adopted convention.

  • Chad Woolley

    In the early years of Pivotal Tracker, people on the beach often were assigned to “help out”. In fact, most of the early Pivots in the ruby practice touched the codebase at one time or another.

    Eventually, the core Tracker development team had to institute a rule: If you want to introduce a cool new tool/gem/pattern, you had to convince the team of its value, AND ensure that it was fully and correctly implemented across the entire codebase. No half-completed “improvements”.

    This rule greatly increased the future maintainability of the codebase.

    — Chad

  • Dennis

    Do you know if Project Monitor is still being maintained? Looking at the GH project, mailing list, and tracker board, development seems to have stalled.

Share This