Thoughts on "Software Estimation: Demystifying the Black Art" by Steve McConnell
I've never had any formal training in software estimation and my hunch is that many of the software developers and engineers I've worked with over the years haven't either. That's not a knock against them, many of them are highly qualified. If anything, it's more a commentary on the typical career path of a developer: Get a degree in computer science and the next thing you know you're out in the world working as a software developer/engineer.
A quick look at the cirriculum of a handful of univeristies with popular undergrad computer science programs show software estimation is not included as a required course and frequently not even available as an elective. As to why is probably better left for a discussion on how computer science and software engineering are not one and the same, but the point being that a lot of us enter the profession without any understanding of what best steps to take for properly estimating projects.
Combine the lack of formal education with the likeliness that "programmers" generally like to write code instead of spending time on administrative tasks (like project estimation) and you have a pretty good recipe for ineffective project estimation.
Adequate estimation is of course critical to any product in any industry. Software estimation has increasingly interested me over the years. I've been involved in software projects of various sizes and have seen how difficult of a task effective software estimation can be.
I just finished reading Steve McConnell's "Software Estimation: Demystifying the Black Art". It was well worth the time. It's an easy read but contains a number of topics, suggestions and points the average software developer could likely spend a lot of time contemplating.
- Software estimates, product target dates and commitments are three different things.
- A single-point software estimate is often more of a target date than an estimate.
- A flaw of single-point estimates is that they lack probability stats on achieving the estimated date.
- The software development industry largely has an under-estimation problem.
- Don't make guess-timations. Always keep metrics on projects. Use that data to estimate future projects.
- Use multiple estimation techniques and look for convergence.
- Even the highest quality estimations early on in a large project will likely contain unavoidable uncertainties.
- Software estimation should be a tool to help support effective project control.
- Sprints are helpful in quickly providing metrics you can use in future sprint estimations.
- Results from software estimation tools can serve as an unbiased third party in a debate over an estimation.
- Various estimation techniques and which techniques apply best to specific projects.
- Where estimation errors can originate from.
- Calculating best and worse case estimations and avoiding common calculation errors.
- Estimate presentation techniques.
- Politics and negotiations involved with estimates.
It was a good read. I really appreciated the practicality of the book. I found myself reflecting on past profesional experiences and idenifying with various challenges addressed in this book. I'd recommend it to anyone involved in software development and look forward to using material in this book to produce more effective software estimates in the future.