Bulldozer00's Blog

The best book I’ve read (so far) on software estimation is Steve McConnell’s “Software Estimation: Demystifying the Black Art“. Steve is one of the most pragmatic technical authors I know. His whole portfolio of books is worth delving into.

Prior to describing many practical and “doable” estimation practices, Steve presents a dauntingly depressive list of estimation error sources:

• Unstable requirements
• Unfounded optimism
• Subjectivity and bias
• Unfamiliar application domain area
• Unfamiliar technology area
• Incorrect conversion from estimated time to project time (for example, assuming the project team will focus on the project eight hours per day, five days per week)
• Misunderstanding of statistical concepts (especially adding together a set of “best case” estimates or a set of “worst case” estimates)
• Budgeting processes that undermine effective estimation (especially those that require final budget approval in the wide part of the Cone of Uncertainty)
• Having an accurate size estimate, but introducing errors when converting the size estimate to an effort estimate
• Having accurate size and effort estimates, but introducing errors when converting those to a schedule estimate
• Overstated savings from new development tools or methods
• Simplification of the estimate as it’s reported up layers of management, fed into the budgeting process, and so on
• OMITTED ACTIVITIES!

But wait! We’re not done. That last screaming bullet, OMITTED ACTIVITIES!, needs some elaboration:

• Glue code needed to use third-party or open-source software
• Ramp-up time for new team members
• Mentoring of new team members
• Management coordination/manager meetings
• Requirements clarifications
• Maintaining the scripts required to run the daily build
• Participation in technical reviews
• Integration work
• Processing change requests
• Attendance at change-control/triage meetings
• Maintenance work on previous systems during the project
• Performance tuning
• Administrative work related to defect tracking
• Learning new development tools
• Answering questions from testers
• Input to user documentation and review of user documentation
• Review of technical documentation
• Reviewing plans, estimates, architecture, detailed designs, stage plans, code, test cases
• Vacations
• Company meetings
• Holidays
• Sick days
• Weekends
• Troubleshooting hardware and software problems

It’s no freakin’ wonder that the vast majority of software-intensive projects are underestimated, no? To add insult to injury, the unspoken pressure from the “upper layers” to underestimate the activities that ARE actually included in a project plan seals the deal for “perceived” future failure, no? It’s also no wonder that after a few years, good technical people who feel that hands-on creative work is their true calling start agonizing over whether to get the hell out of such a failure-inducing system and make the move on up into the world of politics, one-upsmanship, feigned collaboration, dubious accomplishment, and strategic self-censorship. Bummer for those people and the orgs they dwell in. Bummer for “the whole“.