Over the past couple of months, I've been participating in a virtual book club. We had been reading Steve McConnell's book on Software Estimation, and having weekly discussions about the chapters we've been reading. The pace has been reasonable - two or three chapters a week, which equates to about 40 pages of reading per week. Now that we've moved on to the next book, I figured it was time to finally post about the first book.

Mike Eaton was the organizer of the book club, and it's been a great experience thus far. Usually, I'll read through a book, but not have a way to find out what others are thinking. On occasion, I'll come across a blog post reviewing the whole book (kind of like this one!), but I've never really had anyone to discuss the ideas in the book with. By reading the book as part of the book club, I got the chance to just that on a weekly basis.

I think we all started out thinking this was going to provide "The Answer" to how estimates should be done. In reality, there are no silver bullets, and if that's your reason for reading the book, you'll walk away disappointed. The book is more of an encyclopedia of techniques to use during estimation, giving the pros and cons of each, but never really gives an opinion about what the best way is. I guess that makes sense when you consider that every situation is different and unique.

There was one good takeaway from the book that we all kept coming back to: The Cone Of Uncertainty. This essentially says that early on in a project, your ability to accurately estimate a project is extremely low. The further you get into the project and discover the previously unknowns, the more accurate your estimates will be. This makes logical sense when you think about it, but sometimes it takes having it laid out in front of you to truly grasp it. The book also put a number to that uncertainty. At the cone's widest point, there's a 16X difference between the two end points, meaning that any estimate you give early in a project could be 4 times over or under the actual outcome. That's very significant, especially if you're used to putting numbers on paper at that point and committing to dates! It then shows that as you move further in design and nail down what needs to be done, that you can get to a point where your variability can get down to around 25%, which is much more acceptable to start moving forward with commitments than 400%!

Overall, I think the book was worth the read, although I could have done without most of the second section. Reading part one, the first chapter or two in part two, and then the last two chapters would have been a good approach. Those middle chapters were repetitive and drawn out - they went over different estimation techniques, discussing where they apply and where they don't. I think if I was in an estimation situation, I could use that middle section for guidance, but just reading them through didn't do much for me. Still, it was a good book and worth my time.

Now, we're moving on to Working Effectively With Legacy Code, a book I'm really looking forward to discussing!

Tags: Estimation | Book Club | Book Review