David Heinemeier Hansson

December 22, 2021

How we manage programming projects in Basecamp

That we manage all our programming projects in Basecamp is perhaps an obvious admission since its our own product. But it's less obvious to some how that's possible, given the apparent lack of affordances to tie todos, messages, or check-ins together with code commits automatically. Some teams who are Basecamp curious can't seem get over this conceptual hump: How can we organize the programming work, if everything isn't tied together?

The simple answer is: don't. You don't need to string every todo to every commit. Micromanaging that level of detail has the appeal of superficial neatness, but without much if any payoff in additional ease or insight in practical terms. Modern programming projects are already packaged for easy reference and review through the magic of the pull request. That's all the pointer you need.

The vast majority of all feature development at Basecamp has a 1-1 relationship between a project and a pull request. This relationship provides all the tie-in necessary to match the work with the planning, at a coarse level that doesn't rely on micro linking every individual piece together. (I'll write another post about why I don't fancy breaking up the work into multiple small pull requests per project.)

The entire story is told in two parts: The Basecamp project that sets the scope, manages the outstanding work, documents the trade-offs and the considerations. The GitHub repository that holds the code, the per-line review notes, and the results of continuous integration testing.

Let's take the Out of Office feature we just launched for Basecamp. We ran the project in Basecamp as Cycle 6: BC4 Out of Office, and did the nitty-gritty design of How Should It Work in a series of todo threads, like this:

bc3 todo of a feature.png


The entire feature was tracked as three major todo lists: A list for the epicenter (we could just have shipped this alone), a list for the stretch version (we ended up doing this as well), and a list for the integration with the mobile apps. The progress story was told through a simple hill chart plotting these three scopes moving over the hill:

three todolists moving over the hill chart.png


Along side this work of the work, we also used the Basecamp project to have discussions about leaving the campsite better than we found it. Could we move our avatar code in Basecamp to use Active Storage, a recent framework added to Rails?

discussing moving avatars to active storage.png


Occasionally we'd settle quick questions via Campfire that needn't be presented as a big argument:

campfire settles quick questions.png


Then in the GitHub repository, we'd do code reviews, and handle the discussion of the implementation there:


And as you can see on this chop of the commits happening on the repository, none of these commits would have brought additional clarity to the project by being tied to a specific todo or update. And, if one commit really did stand out as being worthy of such a tie-in, you'd just copy and paste the URL to make the connection.

list of commits.png


Programmers are trained in consistency and coherence. They're key properties of writing good code. But sometimes chasing those properties outside the code just don't offset the cost of doing so. Managing projects, be they code or otherwise, is mostly about communication. Making decisions about how things should work, doing the trade-offs to ship within the time allotted. That's the kind of work that benefits from narratives, selective highlighting, and human context far more than it does from some procedural idea of Tying It All Together.

I get that this might feel somewhat alien if you're working at a feature factory pulling tickets from a Jira backlog. That's a very different environment to the one we're cultivating at Basecamp through Shape Up. And as long as you're stuck in that assembly-line mindset, I do think Basecamp probably does seem incompatible. But that's why we're so keen to share the fully integrated story about how we work. From REWORK to It Doesn't Have To Be Crazy At Work to Ruby on Rails to Shape Up to managing all of it in Basecamp. We're here to help people set their sights on the right motivations, give them organizational ideas to visualize such a pursuit, gift the technical tools to implement it all, and manage everything through a system built around all these concepts.

It's all in and from Basecamp.

About David Heinemeier Hansson

Made Basecamp and HEY for the underdogs as co-owner and CTO of 37signals. Created Ruby on Rails. Wrote REWORK, It Doesn't Have to Be Crazy at Work, and REMOTE. Won at Le Mans as a racing driver. Fought the big tech monopolies as an antitrust advocate. Invested in Danish startups.