Honesty, I was expecting very "soft" content, i.e., pages spent over-analyzing obvious points and so on. BUT this description could not be farther from the truth. In Software Estimation, McConnell draws on over a hundred published studies on the topic of software estimation as well as numerous case studies. The book is data driven and based on statistical techniques. McConnell emphases counting concrete project steps and comparing them with previous estimates where as intuiting off-the-cuff estimates is a major no-no.

I have just completed the reading. Not that, I didn't know estimation, nor that I was struggling to do a right kind of estimation. I am already fairly accustomed with standard tools and techniques in the world of professional software estimation. What I found appealing in this book is the approach towards estimation at the start.

Today, I was sitting in an informal discussion session with a bunch of college graduates who barely completed 1 year in this industry. It was an open discussion set, and one point came up on right estimation. Many of them had gone through 20 hour workday regimen during the difficult times of the project, and all of them were convinced that somebody did not do the estimation right. To explain that estimation is not that easy math work like a college paper, I started with a quiz: What's the latitude of Sanghai. And as I continued speaking on estimating the latitude of Sanghai, I found increasing number of approving nods all around the room. Happy me! It was not always the case where I found an immediate place to apply my book reading in past, that too with the nods of approval.

Coming back to the book, I will definitely recommend this book to all software project leaders and project managers to get a feel of the subject and how to address the problem at large. To gain deeper knowledge there are tons of research papers and books waiting for you, but if you are a busy professional, go through this book first.

Basic premise: that "the goal is software estimation is not pinpoint accuracy but estimates that are accurate enough to support effective project control. To that end, a "good estimate" is one that "provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets."

Software estimation is inherently nontrivial. The resulting product is virtually invisible until it is finished---and you rarely end up with the same product that you initially estimated anyway. Early on, requirements are difficult to state (and measure) precisely, and as Rittel stated "the true nature of the problem only emerges as a solution is developed."

Many PM's still believe that estimates are based on multiples of a gut feel. However, the ambiguous nature of software reality requires multiple and varied quantitative methods just to define the estimate space in terms of order of magnitude.

This book provides a basic and superficial description of a number of these methods, including how and when to best apply them. It is an excellent primer to reading other more exhaustive texts (such as Stutzke's Estimating Software-Intensive Systems) and an indispensable desk-reference for Program Managers, Project Managers and Parametricians. Highly recommended.

Despite the fact that most software developers consider themselves engineers or scientists, many mainly rely upon gut instinct for estimation rather than data. The material in this book enabled me to persuade my developers of the limits of gut instinct, to guide them to develop more quantitative methods and to help them predict the precision of their estimates.

Excellent book. It seems like it is more targeted at Project Managers than developers, but it's definitely worth the read for both positions.