The Five Laws of Software Estimating contains several Bunk ideas. let's look at each of the Five
1. Estimates are a Waste
Time spent on estimates is time that isn’t spent delivering value. It’s a zero-sum game when it comes to how much time developers have to get work done – worse if estimates are being requested urgently and interrupting developers who would otherwise be “in the zone” getting things done. If your average developer is spending 2-4 hours per 40-hour week on estimates, that’s a 5-10% loss in productivity, assuming they were otherwise able to be productive the entire time. It’s even worse if the developer in question is part-time, or is only able to spend part of their work week writing software.
The estimates aren't for the developers, they're for those paying the developers.
Estimates can help developers plan work sequencing, needed staffing and other resources, but to say it takes away from their development effort reeks of hubris.
Writing software for money, requires money to be provided, sales revenue to be acquired to offset that cost. This is a business discussion not a coders point of view.
2. Estimates are Non-Transferable
Software estimates are not fungible, mainly as a corollary to the fact that team members are not fungible. This means one individual’s estimate can’t be used to predict how long it might take another individual to complete a task.
This is the basis of Reference Class Forecasting. Write down what the estimates were when you made them, classify the estimates by the categories of software, put those in a sprad sheet and use then again when you encounter a similar class of software. This is standard software engineering practice in any mature organization. CMMI ML 2 and 3 process areas.
3. Estimates are Wrong
Estimates aren’t promises. They’re guesses, and generally the larger the scope and the further in the future the activity being estimated is, the greater the potential error.
This is one of those naive statements that ignores the mathematics of estimating.
Estimate can be guesses, that'd be really bad estimating. Don't do stupid things on purpose. Read Estimating Software Intensive Systems, and learn how to estimate, then you won't be saying naive things like estimates are guesses
4. Estimates are Temporary
Estimates are perishable. They have a relatively short shelf-life. A developer might initially estimate that a certain feature will take a week to develop, before the project has started. Three months into the project, a lot has been learned and decided, and that same feature might now take a few hours, or a month, or it might have been dropped from the project altogether due to changes in priorities or direction. In any case, the estimate is of little or perhaps even negative value since so much has potentially changed since it was created.
Yes, estimates are temporary. They are updated periodically with new information. This is standard estimating process.
Reference Class Forecasting updates the reference classes when new data is available.
5. Estimate are Necessary
Despite the first four Laws of Estimates, estimates are often necessary. Businesses cannot make decisions about whether or not to build software without having some idea of the cost and time involved.
Yes they are. Making decisions in the presence of uncertainty means making estimates of the outcomes and impacts of those decisions on future.
So before applying any of these ideas, ask a s simple question and get the answer.
What's the value at risk for NOT estimating the impact of your decision?
