Constraints only work if they hurt

We run on 6-week budgets for most major product work at Basecamp. It’s not that everything has to done in that time, but the self-imposed constraint makes us try. It’s not a deadline, mind you, but a budget. Deadlines are just excuses for death marches (fixed scope, fixed time). Screw deadlines.

Budgets, on the other hand, instruct us to keep quality high but scope variable. When making decisions on how to fit within budget, we decide to write less software. Fewer features, fewer settings, fewer wouldn’t-it-be-cool-if’s.

Nothing brings clarity to the discussion like “well, there’s only 3 weeks left: We can either do A and B, but not C. Or just C. Which would you rather?”. It moves the debates out of the we-really-ought-to realm. That’s the realm free of compromise and trade-offs. That’s the realm of bloated, late software.

This might make it sound easy to ship great software on time, but of course it’s not. Because like any good constraint, it hurts when its working. We have to kill our darlings all the time. Features, settings, considerations that we really think are important have to be cut constantly. When something you believe to be important doesn’t make it, it hurts.

But it’s also the right thing to do. We’ve proven that time and time again. Things we thought were terribly important in the heat of the argument frequently turns out not to matter at all. And above all, the discipline and the habit of shipping software every six weeks (or thereabouts) is worth some real sacrifice.

We’ve run other intervals in the past, and we sometimes do when circumstances warrant. Our standard used to be two months, but we’d still go a week or two over budget with that schedule. And it’s not clear that the software we shipped was appreciably better. Now we only run on 8-week cycles over the Summer when we work four days a week instead of five.

Shipping software on a budget rather than on a deadline or When It’s Done is a key component to how we’ve written and released so much with such a small team for so long. It’s probably been the most helpful general concept we’ve adopted from agile development. It doesn’t even require a big process, a backlog, or a stand-up meeting. But it will occasionally hurt. That’s when you know it’s working.

Everything is possible but nothing is free

Every developer has been asked whether building a certain feature is “possible”. The short answer is virtually always YES. It’s possible. Software is the clay of dreams; everything is possible.

What those asking really want to know, though, is one of two things:

  1. Can you just build this thing I want, in addition to all the other things already on your plate, without moving any of your estimates? In other words, can you invent additional time or work hero hours to make this happen? The short answer to that question is always no. No, developers cannot bend time, invent time, or be long-term productive by sacrificing their downtime for your special-request time.
  2. Is this “easy” to do? And by “easy”, let’s take the vaguest, most fuzzy definition of the word that the two of you will never agree upon. This is like two kids arguing which car is faster: the red one or the yellow one? Without further information, you’re not going to make much progress on either question.

Here’s a simpler approach: I would like to have this and I’m willing to pay up to that.

That’s a basis for a conversation worth having. It’s rarely enough for a developer to give you a definitive answer on the spot, but after a couple of follow-up questions, you’re at least likely to know whether you’re in the ballpark.

The catch with framing the request like that is it requires the person asking to make the hard analysis. How much is my request really worth? What other things would I give up to have this thing instead? It forces them to bargain with reality, which is much less appealing than charming the developer fairy into just giving them want they want, no sacrifices needed.

And many developers are surprisingly willing to play their part in this fantasy, because who doesn’t want to be thought of as superhero with magical powers? It’s an addictive role, but also a broken one. You only get so many magic spells before your book is done.

Successfully and sustainably making progress on software together is based on an open dialogue about costs and trade-offs. The more we obfuscate those critical decisions, the less likely we are to get what we all really want: The best software for the time and money we have.

Basecamp was built by hunting for bargains under a set-the-budget type negotiation tactic as described above. Well, mostly. We still succumb to wishful thinking every now and then too, but when we catch it in the act, we try to whack it. Let me know how you think we did.