Error types in software and fort construction

CH pointed me to this one. A programming guru classifies errors in a family constsruction project, and relates them to software development. Emphases mine, number 4 is my fave.

Building a Fort: Lessons in Software Estimation - 10x Software Development

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 ... 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!

5. Sweeping numerous little tasks under the estimation rug....

6. Never creating a real estimate. The fact of the matter is that I carried around a rough plan in my head for weeks, but I never actually committed a schedule to paper...

7. All's Well That Ends Well. My kids love their fort, and I had a great time building it. "All's well that ends well" is one reason that companies don't improve their software practices more often than they do. If people like the software that the team produced, and the software is successful, then that reduces the incentive to try to do better next time.