Software Estimation: Demystifying the Black Art by Steve McConnell

Software Estimation: Demystifying the Black Art Reviews

• 
  Marek

  "Software Estimation - Demystifying the Black Art" is a boring book. I read it because I wanted to have tools to discuss the subject, and I think this books accomplishes that.
  
  To me, the first and last chapters which dealt with conceptualizing the problem space in general were the most interesting. The bulk of the book consists of different techniques to actual estimation, which I suppose would open up by actually trying to apply the methods described.
  
  Overall I found the book to be interesting, although somewhat tedious and more geared toward estimating big projects on a high level. For a developer being asked for feature-level estimates it gives some tools for presentation and discussion, but not much more.
• 
  Ha Truong

  An excellent book on software estimation.
  
  Not like other books that scare readers at the first glance with sophisticated math equations, this book naturally comes with the practical methods (what, how, why and caveats). It also provides plenty of tips and diagrams to depict the definitions and methodologies.
  
  Besides, it states issues in reality and how to fix such as the estimation can be impacted by the executives or the marketers, the estimator should defend and make an appropriate commitment (last chapter)
• 
  Taras Fedoruk

  It is a good book full of interesting formulas and laws that you are free to follow while estimating the software development project. It is 4 stars because some of the facts and approaches like counting the lines of code are outdated. Apart from this, it is a decent basis helpful for everyone.
• 
  Marco Bizzarri

  Very detailed discussion about software estimation process.
• 
  Bartosz

  The most straightforward book I’ve found on this subject. Works great as a reference, and a textbook. Highly recommended to anyone who wants to up their estimation game.
• 
  Allisonperkel

  "Software Estimation" by Steve McConnell provides a very broad overview of many ways to reduce the software estimation errors for your development cycle. Like all of Mr McConnell's books, he provides crystal clear writing with tons of techniques that are ready for application in the real world.
  
  One of the many great things about "software Estimation" is the sheer number of methods he gives. From Lines of code, to function points, to similar projects, to industry estimates (broken down by sub category so that database is different from embedded devices), to t shirt sizing, to maintaining development history: he makes it clear that you have a lot of different options available to you. He takes great pains to emphasize that one size does not fit all. Additionally he gives rationales for when the estimate techniques work in a project's lifecycle.
  
  With all the methods described, another point driven home is that software is something of an art and that you can reduce the amount of uncertainty but you can never fully remove it. None of the methods that improve estimation are silver bullets. I love that he draws the line in the sand here. Its very true and in fact he goes a step further, pointing out that on successful projects the "cone of uncertainty" converges as the project matures. The converse is also true. Wise words indeed.
  
  The final chapter feels more like a tack on, however the message contained therein is something that needs to be stated again and again: marketing/management is not the enemy. It is important to remember that everyone has the same goals and that the battle really should be a collaboration. However good this chapter was, it still felt out of place.
  
  There are a few niggling issues that I had. The biggest gripe is that he talks a lot about estimation software packages. In fact, he makes assumptions that the reader has knowledge of these packages. Working in start-ups, I've never even heard of these packages until this book. Its a small gripe, but it did detract. Another issue would be some of the examples on applying the various techniques towards the end of the book were far too glossy and far to dry. I think there was some good information there but you, as the reader, will need to make a few assumptions. Which, to me, is always a dangerous thing. Not as bad as fighting a land war in Asia, but still dangerous.
  
  Overall though, as a software engineer/manager I found this book to be invaluable. The techniques are usable right away and really helped me convey the uncertainty I had in ways that I wasn't able to in the past. I think this should be required reading for anyone who works in the software industry.
• 
  Gustavo Leiva

  Great insights into estimation. Some of the highlights to call out in my opinion:
  - Clear definitions and differentiation of: estimate, commitment, complexity assessment, schedule, confidence level, among others.
  - The author brings up other topics that are usually forgotten when estimating a project, but definitely could impact it.
  - The importance of being clear about the cone of uncertainty and how to use it when creating/communicating estimates and confidence levels.
  - Clarity into when it could be a good time to add more people to a project without actually hurting it.
  - Iterative vs sequential projects.
  - Good references to other books to amplify other topics.
  
  From the management standpoint I value that the topic calls out anti patterns that organizations fall in when requesting for an estimate.
  The book definitely will give you a good tool set to look & create timelines and estimates from an unbiased stand point. And it also makes you understand how to connect the worlds of the people/stakeholders requesting the project and the teams actually estimating and executing.
  
  My only feedback would be that it would be nice to have some more content on Agile projects. The topic is mentioned but there could be more about it. The book does recommend this other book:
  
  https://www.amazon.com/Agile-Estimati...
  
  
  
  
  
  
  
• 
  Erika RS

  Estimation is difficult in software and everywhere else. In this book, McConnell provides the reader with tools to improve their estimation skills. There are no silver bullets -- most of these techniques take work and practice -- but by breaking down the process of estimation McConnell takes it from a black art to something understandable.
  
  The first part of the book covers fundamental concepts in estimation. The heart of the book is part two which discusses many different estimation techniques, pros and cons of each, and times when a particular technique may be applicable. The final part of the book has further discussion of some other issues in estimating.
  
  Although this book is specific to software, the core insights it contains are also useful outside of software. My husband and I are building a house, and as I read this I found myself thinking "if our builder had used some of these techniques, we might have had a more accurate budget and schedule".
  
  This book has made it onto my short list of "must read" books for developers, especially those with no previous exposure to formal discussions of estimation.
• 
  Michael

  Another great book from Steve McConnell. Obviously, subject matter expertize and lots of historical data are key to good estimates, but this book is packed with real world examples and complete explanations when you don't have that. Highly recommended.
• 
  Graeme Canivet

  Solid principles that still apply today
  
  Gets to the heart of real world software estimation, targets, commitments and project management challenges. Still relevant for any modern software project. Will definitely incorporate many of the tips on a daily basis.
• 
  Adrian

  A solid pick if you want to get some leverage the next time your manager has your back against the wall trying to make you commit to some project impossible to deliver in the preseneted timeframe.
  
  You will get a good understanding on what estimation means , how are estimates different from commitments and targets. Once you realise this , your approach with non technical people from your organization will hopefully change radically
  
  There's a lot of useful tips on topics such as estimation errors , planning , the cone of uncertainty and many tools and approaches on figuring out how in deep shit you.are when starting a new project with the given resources or how badly the ongoing one was planned.
  
  This one gets 3 stars since i was hoping for some end to end scenarios like "you receive project X and you do Y,Z,T in this order". I was expecting a bit of handholding and more cohesion regarding the multiple tips and approaches you get familiar along the chapters.
• 
  Bibek

  I read a handful of chapters in a reading group with coworkers to see if we could glean some insights for our own work. It was useful insofar as part 1 provided us with the vocabulary and mental frameworks for thinking about estimation in general. The meatier parts about how to actually go about estimating work felt less directly relevant. The programming languages and practices referred to were somewhat dated (understandable since the book was written 15 years ago) and the recommended techniques generally seemed more useful for large-scale organizations where the projects being estimated take on the order of many months to years to complete.
• 
  Eric

  Every software engineer should read at least the first ten chapters of this book. These are the most insightful chapters that talk about what estimation is for, what to be wary of, and some basic ways of estimating. The biggest, most broadly useful takeaways boil down to a few rules of thumb and a handful of equations, many of which are usefully collected in an Appendix.
  
  The rest of the book is a broad survey of techniques, but many of them are likely only applicable in a big company that has a lot of record-keeping and is able to do things like staff 20 person projects for several years.
• 
  Maxim Chetruşca

  I would actually give this book 4.5 stars.
  
  What I did not like:
  
  - it's a bit old;
  - too much publicity for the software estimation tool the author worked on.
  
  What I did like:
  
  + it actually does its job - a list of gotchas, suggestions and rules of thumb which seem helpful. A seasoned developer will recognize most of the suggestions as thoughts which we all get at one point, then forget. Here you can find them all in one place;
  + really simple to read and easy-going;
  + no rocket science.
• 
  Nathaniel Inman

  First half of book could be called "Applied COCOMO 2", and the book largely presents most of its value to general SDLC practices stringing together a variety of good sources and connecting the dots with applicable examples. For me the largest value was the smallest chapter where he takes those results and shows how to present them to stakeholders for "negotiation". Very well cited sources and organization skills will allow this to be easily used as a reference manual later.
• 
  Bennor

  It took me an awfully long time to get through—it is about as dry as it sounds—but it was worth the effort. There's a ton of useful advice that I should be able to immediately put to practical use.
  
  It was humbling to see how wrong I've been getting some aspects of estimation though.
• 
  Steve Fenton

  McConnell is always well researched and this is no exception. This book covers pretty much everything to do with estimation, including dysfunctions and abuses. A great handbook for estimation.
• 
  Juan

  This is a basic book for any software craftsman, essential after the initial steps of writing code profesionally.
• 
  Peter Aronson

  A solid, readable book on the various software estimation (time, effort, scope, cost, etc.), with a ton of useful definitions and rules of thumb and advice.
• 
  Michał Węgrzyn

  This should be handed to everyone who works in software development as a must read. I plan to read it many times over next years.
• 
  Vander Alves

  Accessible, comprehensive, still relevant, and a far more interesting read than one would expect from the subject—worthy to have on a handy bookshelf.
• 
  Naranmandal Sunrise

  Must read
• 
  Hung

  old school book which does not really fit modern situation
• 
  Omar Trejo

  Simple presentation of potentially complex topics with a very methodological and useful approach.
• 
  Eduard

  I read this as part of my job. As an IT Consultant I was asked to estimate several projects ranging from small (ca. 50 workdays) up to medium (ca. 300-400 workdays) and confirm estimates on big projects (1000+ workdays)
  When you depend on accurate estimates for profitable projects (especially when you are not on time & material), this is the tool to turn to. The intro and the first chapters confirmed many of my previously experiences from ca. 15 years of software development (including many horrible results). The following chapters are then more about how to apply different techniques to avoid the aforementioned traps.
  What I really appreciate about the author is that he doesn't give you prescriptive solutions but instead draws on research and many, many project results to support his conclusions and claims. This is a great departure from many software books I've seen over the years which claim their insights are the one and only and solves so many of the problems other people have been experiencing.
  I've had several discussions where people flat out deny this is possible and therefore see it as an argument for agile development. I've found this way of thinking is more self-serving: I don't want to have to say how long it takes, so I'll not try it at all. The book also shows that estimating the effort to a certain accuracy is possible and which conditions must be met, to make this possible.
  
  Conclusion: For anyone having to lead and organize a software project this is a must-read, while anyone as part of a team can profit from knowing when your leads on the organization is talking bullsh*.
• 
  Simon

  This book gives a great detail description of what it means to estimate applied to the software engineering context. It starts off by defining what an estimate is, common problems with estimates, and the cost of underestimating. It talks about estimation strategies and finally how to apply them and issues that may occur when apply them. At the very least for me it helps me think about estimation more and gives me some tools to use while creating them. I imagine I will be going back and referencing some of the chapters throughout my career. I also think I will print out the list of tips he has through out the book (placed in an appendix as well) and hang it on my wall at work as reminder to myself and others.
• 
  Khang Nguyen

  You can't be disappointed at a work of Steve McConnell. The book provided a well-rounded look into estimation as a process and set of techniques. Though the procedures are more for medium-large project, ones for small projects can be easily derived. As stated in the foreword, the book is not meant to cover the science part of software estimate. However, as software has its firm root in math and estimation is an art with numbers, formulas are unavoidable. Readers are kind of forced to take the formulas for grant, a few complicated one don't come with proper explanation other than "statistical science proved that". Still a good read for small and medium software shops, as well as starter estimators.
• 
  Mohammad Fouad

  After you work for a while as a software developer or leader, you realize that almost every single estimate you make is off by a significant amount. This book is full of practical advice that you can apply in your next estimate.
  
  but the most important take outs are:
  1- you really don't understand estimates, and you make them wrong
  2- you are not alone!
  
  This book is very easy to ready. You could even take all the figures and images in this book, stick them on a paper and you got yourself a visual guide on how to make estimates.