Software Estimation: Demystifying the Black Art is one of those books that came to me just in the nick of time. No sooner had I finished reading it than I had to do a bunch of estimation for a project I’m on. I managed to apply maybe 15% of what I learned in the book and found a nearly 100% improvement in the result.
Steve McConnell is also the author of Code Complete and Rapid Development, so it’s not like he has much to prove. That’s probably part of what allowed him to feel free to take decades of software research (which he thoroughly sited and gave very useful bibliographies to at the end of each chapter) and distill it to easy to understand snippets without any apparent loss of nuance.
Here are some of the gems I took away from the book:
- You really should get in the habit of differentiating among: estimates (how long it’s likely to take), targets (dates the business would really like to hit), and commitments (dates you commit to delivering, which sometimes don’t exactly jive with your estimates).
- Schedule in Months = 3.0 times the cube root of the Effort in Person Months—-this is apparently one of the “most replicated results in software engineering” research.
- Underestimation when you start a project has actually been proven to lead to increased effort for a whole variety of reasons, some of them obvious and some not.
- 40% of software errors are caused by stress, especially schedule stress.
- Projects experiencing schedule stress produce four times as many defects as those that aren’t
- estimates vs actuals can vary by surprising amounts depending on where they are in the Cone of Uncertainty
- There are many known multipliers to software estimation, and at the very top of the list are: the ability of your business analysts (2x), multi-site development (1.56x), required reliability of the software (1.54), and the list goes on.
- and my favorite one of all, one I managed to put to good use on my project: expected case estimate = (best case x (3 x most likely case) x (2 x worst case)) / 6