28 April 2009

Why Most Developers are Rubbish at Estimating

Recently, a local builder handed me an estimate for some construction work on my home. Once my eyes had stopped watering, he calmly explained to me that I wasn’t paying him for what he could do, so much as what he knew. He’d been in the trade for 30 years. “That” he declared, pointing at the estimate “is exactly how much it will cost, and exactly how long it will take”. Three weeks later the work was complete, exactly as he said it would be, and I gratefully handed over a vast sum of money.

Why do so few IT projects proceed in this way? Why are most developers so poor at estimating projects? The first trick, when estimating, is to break down the project into all of its component parts. Accurately identifying all of these steps is difficult, and is a skill that comes with experience. The second task is to assign time estimates to each step. Again, the more times a developer has been through the mill, the higher the likelihood that a given task is one has been seen before, and the more accurate the estimations become.

Even then, given that software development always tends to be on the cutting edge of technology, there will always be a few steps that even the experienced developer will not have encountered before. It is at this point that a developer is likely, if pressed, to give his “best guess” as to how long the “unknown” step will take. It has been wisely observed that the inaccuracy of these “guesstimates” increases exponentially with time. If the estimate is a day, you can expect it to be finished in around a day. If the estimate is a week, it will probably be finished in 1-2 weeks. If the estimate is a month, then the developer really has no idea how long it will take.

Any step that is estimated at over 1 week is a danger signal. Any step that none of the team has encountered before is an “unknown” and therefore a risk. Instead of “guesstimating” such steps, the developer should apply solid three-valued logic. If a step is “unknown” then a NULL should be inserted into the time column for that step. Of course, thanks to NULL propagation, that means the entire project timeline is NULL. The developer must then insist on having time to prototype these NULL steps, so that estimates can be made based on hard evidence, rather than hunches and guesswork.

Inevitably, there are many “agile” techniques, such as planning poker and velocity measurements, which you can use to produce more accurate project estimates. Most of them are well-documented. However, the biggest problem still remains that the IT industry, unlike the building trade, is notoriously bad at retaining experience. In the main, companies hire and pay developers based on what they can do (write code) rather than on the knowledge that comes with experience, such as effective project estimation and management. If these skills were properly valued and rewarded, the industry would do a better job at retaining experience in the role, and the development team’s estimation skills, like fine ales, would refine and mature with age.

Cheers,

Tony.

Keep up to date with Simple-Talk

For more articles like this delivered fortnightly, sign up to the Simple-Talk newsletter

This post has been viewed 2031 times – thanks for reading.

  • Rate
    [Total: 0    Average: 0/5]
  • Share

Tony Davis

Tony Davis is an Editor with Red Gate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the Simple-talk.com and SQLServerCentral.com websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his Simple-Talk.com blog or his SQLServerCentral.com author page.

As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management.

In his spare time, he enjoys running, football, contemporary fiction and real ale.

View all articles by Tony Davis