59 of 61 people found the following review helpful
Format: PaperbackVerified Purchase
McConnell immediately differentiates between software estimation as a science and software estimation as an art within the first pages of the introduction to this work - he explains that while software estimation research is currently focused on improving estimation techniques so that project results are achieved within +/- 5% of esimated results, the techniques of which are best included in commerical software estimation tools that are used to pursue the science of estimation for very large projects, the typical software organization struggles to avoid estimates that are incorrect by 100% or more, and Software Estimation discusses the estimation techniques comprising, although not limited to, the art of estimation that will reduce estimation error to about 25% or less, which is what the vast majority of software projects need. This book is absolutely the best software estimation text I have read to date. As Joel Spolsky mentions on the back cover of the book, the vast majority of software project managers still think that estimates are based on multiples of a gut feel. This philosophy completely ignores the vast body of research and hands-on experience of the last few decades. McConnell explains with sufficient depth all of the ways to create "ball park" estimates, and if there is one chapter of this book that you read, Chapter 4 "Where Does Estimation Error Come From?" is the one that I recommend - the explanation of the Cone of Uncertainty is so well explained that anyone can understand it. Although I have never read Code Complete by the same author, I did purchase Rapid Development several years ago - and I must say that McConnell (or at least his editors) has vastly improved his writing skills. This book is less than half the size of Rapid Development, and while I fell asleep while reading that book I was able to conduct a cursory reading of over half of Software Estimation in one evening and immediately apply some of its concepts on a work project the following day. A great modern follow-up to The Mythical Man-Month by Brooks and an excellent primer to reading SEI's Estimating Software-Intensive Systems by Stutzke on the science of estimation.
45 of 50 people found the following review helpful
I must admit, I was very surprised to see an excellent source on software development time and cost estimation from Microsoft Press. However, when I saw that the author was Steve McConnell, the author of Code Complete (which I thought was a great book) I knew that this book would have something to offer.
His definition of the purpose of software estimation is important: "The primary purpose of software estimation is not to predict a project's outcome; it is to determine whether a project's targets are realistic enough to allow the project to be controlled to meet them."
From this premise, the author continues to prove that software estimation is about determining if you can control a project to bring it in reasonably close to the organization's targets. In addition to this, Mr. McConnell's arguments for overestimation being better than underestimation are rather good and have convinced me to continue using my risk time and budget items that I've been using and recommending to others.
In chapter 4, the author identifies four main sources of project estimation errors:
-Inaccurate information about the project being estimated
-Inaccurate information about the capabilities of the organization that will perform the project
-Too much chaos in the project to support accurate estimation (that is, trying to estimate a moving target)
-Inaccuracies arising from the estimation process itself
That last one presents the need for me to give a little more information. The author suggests that bias and subjectivity of the estimator cause major estimation errors in the estimation process. This is proven through exercise case studies of time estimation in training classes. The author found that the more "control knobs" (impacting factors considered when estimating the project) used in the estimation process the greater the probability of variance in the estimates. He attributes this to bias and estimator subjectivity and it makes a lot of sense.
In the end, this book will make you a better estimator and project manager and I highly recommend it.
Tom Carpenter, Author: Wireless# Certification Official Study Guide, CWSP Certification Official Study Guide, Project Management for the IT Pro, and Foundations of Effectiveness
47 of 54 people found the following review helpful
This is Steve McConnell's latest published effort on software engineering. The book is divided into three parts: estimation concepts, techniques, and challenges respectively. The first part of the book, on concepts, is just a broad overview designed to convince the software engineer of the value of estimation and how, done incorrectly, it can mess up what would have been a successful project. The second part, on techniques, is the meatiest part of the book. Here the author combines tried and true computational techniques with your own judgement and reminds you to get the expert opinion of other people too when estimating a project. Finally, the third and last part of the book, on challenges, talks about how you must think "out of the box" when you confront a software project whose size, effort, and schedule may be hard to quantify completely. Finally, McConnell points out the importance of politics and group dynamics in general in estimation. This is important, as many software engineers and project managers tend to be lone wolves that want to go off in a corner and solve problems by themselves. I highly recommend this book to all software engineers and particularly to software project managers. Amazon does not show the table of contents, so I do that here:
CRITICAL ESTIMATION CONCEPTS
1 What is an "estimate"? 3
2 How good an estimator are you? 15
3 Value of accurate estimates 21
4 Where does estimation error come from? 33
5 Estimate influences 55
FUNDAMENTAL ESTIMATION TECHNIQUES
6 Introduction to estimation techniques 77
7 Count, compute, judge 83
8 Calibration and historical data 91
9 Individual expert judgment 105
10 Decomposition and recomposition 113
11 Estimation by analogy 127
12 Proxy-based estimates 135
13 Expert judgment in groups 149
14 Software estimation tools 157
15 Use of multiple approaches 165
16 Flow of software estimates on a well-estimated project 171
SPECIFIC ESTIMATION CHALLENGES
17 Standardized estimation procedures 181
18 Special issues in estimating size 197
19 Special issues in estimating effort 207
20 Special issues in estimating schedule 221
21 Estimating planning parameters 233
22 Estimate presentation styles 249
23 Politics, negotiation, and problem solving 259
A Estimation Sanity Check 271
B Answers to Chapter 2 Quiz, "How Good an Estimator Are You?" 273
C Software Estimation Tips 275
14 of 14 people found the following review helpful
on January 11, 2007
There's a number of books out there now on software estimation, certainly more than there were a few years ago. I've worked my way through a few of them as I found myself involved in software estimation for larger (50 person +) projects that required a little more than the seat of the pants guesstimating techniques that so many of us IT project managers use with the usual results. Doesn't matter so much on smaller projects, but on large multi-year projects inaccurate estimates can have a deterimentary effect on one's career.
The book really does demystify estimating. It does a good job in Part 1 (5 chapters) of explaining crtical estimation concepts - very important for the neophyte at more formal estimating. Part 2 (12 chapters) covers a range of "Fundamental Estimation Techniques" and does it really well. There's enough information to get you started without being overwhelming
Part 3 (Specific Estimation Challenges - 6 chapters) covers challenges you will face with your estimating and presents useful practical approaches to these. All in all, it's a very useful and practical reference book for all those involved in estimating and presented at a level that the beginner can absorb and use practically. It doesn't overwhelm with detail on any one technique, it's more an introduction to the field, but an introduction that will get you started successfully and form a basis from which you can specialize further.
Steve McConnell's a well-know author with a number of useful books published previously - "Rapid Development" and "Code Complete" in particular. He's gpt experience in the field and he writes well, the books coherent, logically structured and it won't (unlike so many technical books) put you to sleep.
22 of 24 people found the following review helpful
on November 10, 2009
Format: PaperbackVerified Purchase
This book is full of statistical information. If you are already a software estimator, then this book will probably help you. However, the subtitle, "Demystifying the Black Art" seems, to me, to mean that the book will help you learn to do a software estimate. Not learn how to do it better, but learn how to do it, period. That is not what this book is about. It is about doing it better. If you already know the basics of function point or line of code estimation, then this book will probably help you make *better* estimates. However, if you want to learn the "black art of estimation", then this book will not demystify anything.
I think overall it is a good book, which is why I gave it three stars. However, it is very inappropriately titled. If you already know the basics of software estimation, then there is probably not any mystery for you. This book would have been better subtitled, "Enhancing the Black Art", or "Getting your black belt in Software Estimation".
I suppose that once I learn how to estimate software this book will be more beneficial.
23 of 26 people found the following review helpful
on March 15, 2006
Format: PaperbackVerified Purchase
This is a great book for software project managers, or any professional directly involved with the difficult task of predicting how long will it take and how much will it cost to develop a software project based on its initial requirements/scope definition.
Steve McConnell is an essential author in regards to software development issues, and this book delivers on its subtitle: "Demystifying the Black Art", showing the main aspects involved in software estimation and how it is possible to produce reasonably accurate estimates using techniques based on things like group work, personal experience, expert judgement, past history and a lot of common sense. Chapter Four ("Where Does Estimation Error Come From"), with its description of the "Cone of Uncertainty", is a must-read for those who want to understand how good an estimate can be, and where we make the most common errors so we can avoid them.
The book doesn't delve deep into any specific technique, what makes it more useful and easier to read, since some techniques are so complex that it takes hundreds of pages to describe them well. I believe it will become another classic, like "Rapid Development" and "Code Complete"!
8 of 9 people found the following review helpful
on February 9, 2007
Format: PaperbackVerified Purchase
Many of us have been reading Steve McConnell for quite some time and thoroughly enjoy his writing. This book targets a wide audience from those who are completely new to the estimation process (as are the engineers in the industries I serve) to those who are at bit familiar and need more details.
Steve begins the book with a justification for estimation and highlights the import distinction that estimation is not a project plan nor is it a target commitment. Rather estimation is the process of assigning probabilities to completion timeframes for a project. Steve helps the reader understand the process of estimation such that we don't make many of the common mistakes on our projects. Steve also looks into a variety of types of estimation processes. The book is filled with practical advice as well as detailed methodologies, hence it will satisfy a wide range of readers. Finally, Steve doesn't just end the book, but provides plenty or resources for further education.
However, someone who is in an organization with a very strict set of procedures for estimation might not find the depth of detail desired, but she will gain a deeper understanding of the rational behind the estimation strategy that her employer has chosen and she may still glean a few tips.
11 of 13 people found the following review helpful
on April 1, 2006
The key ideas are collect historical data and count/measure what you can. This is really a book about good managerial practises that uses the "Black Art" of estimation to draw people in.
Destined to be a classic. I only rate it as 4 stars because I feel all information is easiest to remember if it is presented in story form, and while there are stories in this book, more stories and a few less charts would suit me better.
One other thing is that there is not a lot of practical help for collecting the historical data that will make your future estimates more accurate. Maybe there is a need for another book on this topic.
9 of 11 people found the following review helpful
on April 5, 2006
I was recently talking to a company that wanted me to do a small coding project for them.
I said, 'I think by next week I can have an estimate to you about how long I think this project will take.
'Next week and estimate, no you don't understand, next week I'd like to have the project completed.'
I didn't do the project. I imagine he found someone else who accepted the task. I don't imagine he was satisfied with the result.
The old standby says: 'On time, on budget, working; pick any two.'
I've got to say though, the techniques given by Mr. McConnell just might help. He provides a framework for at least making an estimate of the software development time. Following this framework will provide you with the detailed information to make at least a reasonable estimate. He describes several different techniques, and suggests using these multiple approaches to see how they fit together.
Today though I just read that the new Microsoft operating sistem code named Vista is delayed. I would have thought that they had as good an estimating system as anyone.
3 of 3 people found the following review helpful
on September 19, 2007
Format: PaperbackVerified Purchase
I've been a great fan of Mr. McConnell's work since I first read Rapid Development and the original version of Code Complete, Second Edition back in the mid 1990's - both of which are books I highly recommend for anyone leading software development projects or teams.
The subject matter here is much more focused than in most of his other work - dealing with a specific aspect of project management, rather than management of projects and the software development process as a whole; but, as with his other works, Mr. McConnell's Software Estimation is clearly written, well researched, and takes a very practical "hands-on" approach to the topic at hand. You will find it readable and packed with useful information. His conclusions and recommendations are well supported with references to the source material from which he derives them, and he does a good job of giving us a well balanced view of the relative merits, cautions and how best to utilize each of his recommendations.
The book is a fairly easy and straightforward read: my first pass through it took just a few hours, and I experienced one or more of those "aha!" moments of revelation with almost every chapter.
In Part I of the book, he presents overview of what Software Estimation is - and isn't; its value; what factors influence estimates; and also challenges the preconceptions all of us have with regards to software estimation. He often delves into some statistical examples to illustrate or prove his point, but these are easy to follow, and should not strain your brain too severely!
In Part II, Mr. McConnell describes a reasonably large number of software estimation techniques - describing how they work; the value, merits and challenges of each; and how to chose when (and why) to employ each one.
Part III was of the most value to me - focusing on "Specific Estimation Challenges" in the areas of estimating project size, effort, schedule, activity breakdowns, cost estimates, and metrics related to defects.
The final two chapters - 22 and 23 - of this book will be of immense value to you; as they focus on how to present estimates to others in ways that will be of most value in your attempt to provide a clear and balanced view of your project's costs and benefits to the organization. They also provide valuable tips on how to prepare and present yourself when facing the challenges that most of us (who spend more time with computers than people) encounter when trying to communicate with executives and nontechnical individuals.
In my opinion, this book will serve not only as an excellent introduction and guide to the discipline of Software Estimation, but is also an excellent reference work that you should keep close at hand: you will be digging into it regularly whenever you are managing a software development project!
In summary, this volume is yet another winner from Steve McConnell, and I recommend it highly for anyone in a leadership or senior role in software development. Five Stars!