Top Software Estimating Mistakes

Aside from a complete lack of planning, this list is about categories of software development that people are aware of during planning, but horribly underestimate. Even smart, experienced people that are usually pretty accurate with their estimates can miss the following things by a mile.

In order from bad to worse in terms of project risk:

#4: The Amount of Testing Required For a Shippable Product

This is actually one of the better known mistakes, especially if you've read The Mythical Man Month. Unfortunately, not enough people in our industry have. And even those that are well aware of the problem are often hard-pressed to effectively address it because it happens at the end of a project, when the buffer (if you even had one) has already been spent on earlier phases.  It is one challenge to build a piece of a system, and it is an order of magnitude more difficult to build an entire cohesive system.  Yes, test-driven development and better unit testing attitudes, tools and techniques have made a drastic improvement in the right hands, but that last mile always takes much longer than you thought it would when you're trying to put all the pieces together.

#3: Building Uncommon Features
By uncommon features, I mean those features that are treading new ground in some aspect of the tools used to provide those features. For example, nowadays AJAX support is pretty well included in most browsers and development frameworks. But when the functionality was first made available, it was a total bear to develop anything with it. A current example of this is the new features available in HTML 5. Bleeding edge? Yes - blood spent by developers cutting themselves as they fumble through the learning curve and mature the specification.

Knowing the problem is half the battle for these mistakes, and tackling each aspect in a simple and direct way is the best method. If you think the benefit for a particularly ground-breaking feature is worth it, go for it - just remember that it's not going to be predictable, and you will run into some very difficult technical problems that may have already been solved in more traditional ways.

#2: Reporting
The required energy for data reporting is often neglected, with heavy consequences. Why?

• The domain of the data being reporting on is often a foreign concept to the people building the software, so we don't know a lot, and miss a lot of important details.
• Reporting typically requires the rest of the system to be built first, and since it comes last, it's often the last thing on people's minds.
• Flaws in the reporting design can often cause a major ripple effect on the parts of the system that were built to provide that reporting data. This means massive refactoring, and gets even worse if you don't have good automated tests.
  

#1 - Data migration
Lucky is the project that doesn't involve data migration, because it hurts. It's no fun, it's messy, the business doesn't nurture it, and it almost always goes way over the estimate. Experienced managers will know when a data migration effort will require its own sub-project, with a separate team and early schedule start. Inexperienced leaders will scan a table structure and some sample data, and slap a 20 hour estimate on what turns out to be a 200 hour debacle. Martin Fowler discusses this in his bliki here. As is often the case, he sums up the problem and advice better than just about anyone else can.


So the next time you've got an estimate sitting in front of you, be sure to think about these categories of tasks and think hard about what it'll really take. Then double it. And add 30%.