Startup Series Part 4 Deadlines

The question of deadlines is one of the most divisive issues in software development today. Business-people despair at developers’ inability to meet goals, while developers lament the latest unachievable deadline imposed by their pointy-haired boss.

In practice, there is often a common cause of this malaise. If your team doesn’t have an agreed scope with sufficiently granular time-estimates for each component piece of work, your project will inevitably overrun, and sometimes by an order of magnitude.

Scoping a project

The solution is to come up with a scoped deadline - a date in the future by which you will have implemented an agreed list of features or functionality. Crucially, each of the features needs an estimate of the amount of time or effort required to complete it, similar to some styles of Agile software development.

The only effective way to estimate effort is to break the project down into chunks of work that can individually be estimated. In no case should any chunk be more than 2 developer-days, and ideally they’d be around ½ a day each (4 hours). There are lots of methods for actually coming up with these numbers - Planning poker is one neat collaborative solution, or Joel Spolsky’s Evidence-Based Estimation is also interesting.

Fundamentally, developers should be the people saying how long a given chunk of work will take. Whatever system you use, it’s essential to have a relationship where developers feel like their judgment is respected and the business-side of the company trusts developers to put in a reasonable amount of effort. At the end of the day, even the best estimation techniques can’t fix a broken culture.

The alternative, an “it’s done when it’s done” attitude, is dangerously counterproductive - if there’s no pressure to hit business goals, technical decisions will tend towards feature-creep and perfectionism.

Why scoped-deadlines are useful

As far as I can see, there are 3 main benefits of scoped deadlines:

It makes you iterative - forcing everyone involved to ask “is this feature really necessary?”. You will always have more development work than time available, so choosing what to work on is a crucial skill. If you strive to keep your deadlines around 2 weeks, you will prototype very quickly, building only the features you really need. Half the time, customer feedback will change what you saw as “version 2” anyway.

Second, it prevents scope creep during the project, as you’ve locked-in the features that are going to be delivered. This is good for both developers and business-people. For the former, it encourages a  pragmatic approach to the quality-vs-speed tradeoff - personally, it helps me check the urge to refactor code when it isn’t strictly necessary. For the latter, it provides a positive response to the perennial request of “can you just implement XYZ for me?”. Sure - in the next version.

Third, it can sometimes good for motivation & productivity, for some combination of people, teams & problems. I find deadlines energising - crossing to-do items of a list, and delivering impressive new feature motivates me. It’s a very tangible way for a team to see that they’re making progress, and people love being part of success. But it’s certainly the least important of the three.

Deadlines in practice

As a project progresses, you should be regularly deploying your code - use a feature-switch to keep new work visible to only staff or small segments of your user base. This is very important because it’s a leading indicator of missed deadlines. If you’re halfway through your “sprint”, and no code has been deployed, you’re likely going to overrun. It also helps catch bugs early, and makes you consider how your code will interact with the existing codebase from the very start.

Even with this advice, you sometimes just won’t hit your deadlines. It might turn out that the version on open-source library you’re using isn’t compatible with a new tool you want to implement. Unexpected problems crop up. While I don’t think it’s a terrible thing to work a couple of late nights if your project needs to get back on track, it’s very different if the scope of the project has fundamentally changed.

Retrospectives are a good way to identify any patterns in scoping problems - if you highlight areas that consistently overran, you’ll get better at spotting them in future.

On the other hand, be quick to celebrate your successes. Releasing code from behind a feature-switch to your general user-base is a great time to gather the team and reflect on your achievements.

Discuss this post over at Hacker News