Software Estimation - Lessons & Insight

I found the two blog posts below extremely interesting, insightful and especially timely; considering that I am currently doing estimates for a project at my company. Both of these articles raise very good points about software development and estimation. I have included my key takeaways from these articles as well. I would encourage you to take the time to read both articles.

NOTE: Please keep in mind that Steve McConnell is one of the industry leading authorities on software development estimation.

Steve McConnell in the Doghouse by Jeff Atwood

"Steve got subsumed in the unpredictable details. This completely mirrors my software project experience. Often, you can't even begin to accurately estimate how long something will take until you start doing it. At least some of it. That's why so many teams turn to agile, iterative development techniques; part of each iteration involves exploring all those unknowns and turning them into slightly-less-unknowns for the next iteration. The faster we iterate, the closer we get to an accurate estimate, and the more work we get done along the way. We plan by doing."

Building a Fort: Lessons in Software Estimation by Steve McConnell

"1. Numerous unplanned problems collectively added up.

2. Underestimation of unfamiliar tasks. My estimates weren't too far off for a lot of the work that I'd done before. But some things, like mapping out the site for the footing holes, I assumed would be 15-30 minute task ended up taking several hours.

3. Not decomposing big tasks into smaller subtasks. I'd planned out my project in whole days. At a birds eye view nothing seems obviously wrong with planning "frame the fort in one day." But when you break it down and say, What's involved in each of the 4 walls, and then you realize that one wall includes a door, another wall includes an angled top plate, a third wall includes an angled top plate and a window, and so on, and then you think about what's involved in each one (measuring, cutting, checking for square, recutting anything that wasn't quite right, tilting the wall up, checking again for plumb and square, attaching and then removing the temporary supports, etc.), you start thinking, can I really do a whole wall in 2 hours? If the answer's even close to "no," then you start to realize that the whole estimate for that big task is probably wrong.

3. Using overly round time units.  Using round units like "1 day" contributes to not thinking hard enough about decomposing large tasks into smaller tasks.

4. Substituting a target for an estimate. I had 7 days to do the project, and my estimate turned out to be 7 days. That's a little suspicious, and I should have known better than to make that particular mistake!"