Failing Forward

ETAs on projects are among the very most necessary evils of software development. Why are they necessary? For a slew of reasons. Think about it – you don’t hand your car to a mechanic without asking him when he’ll be done fixing it. You wouldn’t pay a plumber to renovate your bathroom without finding out exactly how many days or weeks worth of mornings you’d have to walk next door to take your showers. In the same light, we cannot, as software developers, expect our overlords to agree to sending us nice pretty paychecks every Friday without any [reasonable] expectation of when we will deliver them their product.

So why are estimates evil? Well, we don’t have to discuss this one in great depth. Come on, they stink! Right? Think about it, you’ve got a large project ahead of you. One that involves multiple languages and protocols, different APIs, synchronization across processes and maybe even machines, mutual exclusion, exception handling, and/or whatever the case may be. And you’re supposed to [accurately, and with a straight face] tell the guy standing in front of you – who has NO idea what this project entails – when you’ll be done. Yeah… estimates are can be rough. Especially if it’s a project that’s relatively novel.

In the past, I struggled trying to get past the barriers to be able to honestly give relatively accurate predictions on software delivery times. But in a stroke of creativity (I don’t get these often, so it’s always nice when it does happen) I stumbled across the perfect analogy.

Picture yourself in Los Angeles. In a vehicle. Now, in twenty seconds or less, I want you to try to estimate how long it would take you, from there, to drive cross country to New York City. Got it? Of course you don’t. It’s difficult enough to even know where to start, unless you’ve actually done this kind of thing before. You can go on Google Maps, and it’ll estimate for you (1 day and 17 hours if you’re feeling a bit too lazy to follow the link). But will it really take this long? Can Google account for traffic jams? Accidents? Bad weather? Police? Detours? Potty breaks? Food breaks? Mechanical problems? Refueling? Sleeping?

Of course not. As much as I’m a Google fan, it’s not that good [yet].

I’ve found this analogy to be strikingly apropos. The perfect way to explain to your manager why exactly it is so difficult giving software delivery estimates. But it doesn’t help anyone who still actually needs to learn how to estimate projects with any degree of accuracy. You can read the Five-Minute-Task Time Estimate Worksheet. This is a good lesson for anyone new to the game – and hilarious for anyone who isn’t.

So, with all I’ve written thus far, you may by now be expecting some revolutionary, well presented, possibly alliterative, three step guide to producing accurate estimates on software projects. Well, here it is – get off your duff and start working. There is nothing you can be taught in this regard, in my experience. The intuition one may seem to have regarding project estimates has only been earned through much development. Many iterations of seeing projects (however large or small, personal or corporate) go from conceptualization to implementation.

Sorry to leave you high and dry, but experience is, after all, the best teacher.