Estimating development time of software is one of my least favorite things to do. Usually, I’m pretty good at it, but that doesn’t change the fact that it’s

• Time consuming
• Often grossly inaccurate
• Usually done while flying by the seat of your pants, with a marginal (at best) understanding of the functionality that you need to estimate.

I’ve always been a pessimistic estimator, and it’s something that people I’ve worked with for a long time understand and appreciate (even if they make fun of me for it, at times).

Some people might think it’s crazy to be a pessimistic estimator, because any estimate that you give to a client that’s padded by 50 or 100% is potentially going to be high. It might be a lot higher than some other shop who might totally low-ball an estimate just to land a contract.

In my opinion, in my way of doing business, the risk of a dissatisfied customer from a blown budget due to a low-ball estimate is significantly greater than the risk of losing a few contracts because of pessimistic estimates.

I would rather estimate high and exceed expectations by coming in well under budget; even if it means that I lose some work along the way because someone felt my estimates were too high.

Although this topic is something that should be obvious to everyone by now, as it seems to be beaten to death on a regular basis (in a good way), I am still amazed at how many hiring companies still place stuff in their hiring ads like:

• Must be able to juggle multiple projects simultaneously
• Excellent multi-tasker
• Ability to productively work on several projects concurrently

As a matter of fact, this jibberish nonsense used to be something that I put on my resume – until I realized that, well, it’s simply not true.

The latest tidbit I’ve read about this comes from a link to Coding Horrors that I noticed on Joel’s reddit site. The long and the short of it is that you effectively lose 20% of your time (due to context switching) by adding a a single project to your current workload. It only goes downhill from there (as additional projects are added). That 20% isn’t “lost” because that’s how much of your time you are now spending on the second project. That 20% is time that is flushed down the toilet, never to be recovered.

Let’s use a good concrete example. If you spent 4 hours in the morning working on Project A, and after that 4 hours your boss tells you that it’s time for you to start working on Project B, you can expect to flush the next 1 hour and 36 minutes (20% of an 8 hour day) down the toilet as your brain tries to forget the 600 things that you were remembering as you worked on Project A, and tries to lookup the 600 things you need to be remembering to work on Project B. This effectively leaves 2 hours and 24 minutes of productive time for Project B before you (hopefully) go home to watch Start Trek: The Next Generation re-runs (and/or an episode of 24).

He cites other great sources, more from Joel on programmers and quiet working conditions (see point 8). Not to mention this article and some great stuff from Kathy Sierra (who’s Creating Passionate User’s blog is nothing short of absolutely fantastic) stating that multi-tasking makes us stupid.

So, in summary:

• Get quiet working conditions for your developers
• Put them on one project
• Give them a spec, and leave them alone. If they’re any good, they’ll come and ask you questions when they need to clarify something.