Deadlines in software have bad press, for a reason. Say “we need to release this version at this date”, and you are stressing everyone out. Now, say “we need a version of this at this date”, and you are actually helping to ship.
I learned about this idea of fixed deadlines and negotiable scopes from Basecamp many years ago, way before joining them, and it influenced the way I work tremendously. I mostly do infrastructure projects these days, where Shape up isn’t always a good fit, but timeboxing and scope-hammering are still essential parts of my toolbox:
- Early in the project, as a self-defense mechanism to avoid too much up-front work, thinking or design.
- At build time, to avoid getting derailed by adding features or anticipating needs.
- At release time, to avoid aiming for the perfect version of something and, well, shipping.
I used to be very bad at this. I tended to overthink, and I tended to overbuild. Then, of course, some painful lessons taught me to stop considering time as something infinite. Or, in other words, to start valuing how finite time is. Today, I rarely work on something meaningful without a mental deadline for it, not for Basecamp or anyone else, but as a decision-making tool for myself.
Like with being mindful about development costs, this is easier said than done. When you love building things, shipping imperfect and incomplete stuff on purpose is hard.
For example, let me tell you about how console1984 was shipped to the public. We missed a proper tool for doing console audits, so we planned building one. Auditable consoles were also a big reason to use Active Record encryption in the first place, and we wanted to open source this technology too.
The project implied storing audit trails in the database, building an auditing tool for those, and open-sourcing the whole thing. We work in six-week cycles and I started mine with an unexpected Action Cable memory leak, related to a recent Rails upgrade, that took me a long time to track down. At the same time, we had several projects in the line for Basecamp 4 and HEY. My appetite for the project was limited, but I wanted to get it out before moving to something else.
So when I started working on the project I set a mental deadline of one week for it. I started on a Monday and I had something to show that Friday, but it finally took me one week and a half to wrap everything up. This was the first PR in console1984 and this was the announcement.
The one-week deadline helped tremendously. It made me say “no” to everything that wasn’t essential. Now I had a long list of things I wanted to add in future versions, and a shipped product. The alternative would have been a long list of things in the works and nothing to show. A deadline is what really made the difference, nothing else.
Put deadlines to work at your service.