www.hackification.com

I spotted a question over on StackOverflow the other day that piqued my interest – “How do you handle scheduling/deadlines around programmers?” – and I thought I’d note down my thoughts since I’ve noticed that a lot of people either confuse deadlines with estimates, or feel there’s some sort of battle between programmers and managers.

The basic difference is this:

• Deadlines come from external sources, for example, “Feature X needs to be ready for the summer trade show”.
• Estimates come from internal sources, for example, “Feature X will take me N weeks to complete”.

Generally, the sales/marketing department will create deadlines, and the development team should create estimates. Note that word ‘should’ there – I’ll talk about what happens if that’s not the case in a moment.

Generally, problems only occur if the deadline is shorter than the estimate. Let’s face it, if the deadline is six months away, and you estimate the task will take three months, then so long as your estimate is roughly accurate, then there’s not going to be too much stress. (Of course, you really ought to use the remaining spare months constructively).

If the deadline is shorter than the estimate however, then that’s when the problems start. Here’s a few hints to help ease this situation:

1. Hint for managers: Let the person doing the work create the estimate

In many programming environments, the same person creates both deadlines and estimates: the programmer is given a task with the words “you have N weeks to complete this”. This is bad for two reasons: one, the task is unlikely to be completed in the allocated time, thus missing the deadline, and two, the programmer is likely to feel stress and loss of motivation. Basically, you’re fooling yourself, and telling the developer you don’t think they’re capable of estimating.

If you’re the sort of manager who does this, it’s important to understand that even if you don’t let the programmer give a formal estimate, they will have an informal one in their head anyway, so they’ll know from the outset whether they feel able to hit the deadline. Impossible goals are demotivating and lead to reduced performance.

2. Hint for managers: Don’t override an estimate with a deadline

If you ask for an estimate (and you should), and it isn’t what you want, don’t just overrule it by saying something like “well it has to be done sooner”. This is another sure route to demotivation. If you don’t like the answer, the only real options are:

• Ask the developer for a more accurate estimate (but this is only an option if you have reason to believe the estimate is inaccurate – see points 3 and 5 below);
• Ask (or force) the developers to work overtime;
• Trim features;
• Or of course, miss the deadline.

If these options all seem a little confrontational, that’s because they are: you can either admit that, and work towards a compromise in a professional manner, or you can pretend otherwise, and end up in an abusive, passive-aggressive, or just plain nasty stance.

3. Hint for developers: Respect for your estimates only flows from accurate estimates

If you’re a programmer in the situation above, the best way to convince management that you should be making the estimates (and that they’re worth anything) is to provide accurate estimates. If you always significantly over- or under- estimate the time required, there’s no incentive for the manager to stop providing their own (inaccurate) estimates.

4. Hint for developers: Accurate estimates come from tiny tasks

Use divide-and-conquer to estimate times. The finer-grained the tasks are, the more accurate the estimates are. Split the entire task into sub-tasks of no bigger than a day. This forces you to really think about what’s involved in coding each task. The shorter the task, the more accurate your estimate will be. If each of your sub-tasks are a week (or longer) in length, you’ll likely be way out.

5. Hint for developers: Review your estimates after the event

Don’t just “fire and forget” your estimates. At the completion of the task, review what areas you were and weren’t accurate with. Make a note of your ongoing accuracy: when your boss challenges your latest estimate you’ll have cold hard evidence that your estimates are accurate.

6. Hint for marketing: Explain the reason for the deadline

So often, a deadline comes down from on high with no reason, with no added explanation other than a threat should the deadline be missed. Developers wonder what all the fuss is about, and management can’t understand why the programmers aren’t working extra hard. Result: no-one is happy.

Hopefully, there’s a good reason for the deadline – so tell everyone. If you’re worried you’ll lose a big sale if the new version isn’t ready soon, then explain that. If the only thing stopping a major customer using your product is one or two last features, then explain the situation: X thousand dollars profit if the features are coded in a timely manner, or no extra profit if your competitor gets there first.