Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Other Sellers on Amazon
+ $3.99 shipping
+ $3.99 shipping
Software Estimation: Demystifying the Black Art (Developer Best Practices) Paperback – March 1, 2006
Frequently bought together
Customers who bought this item also bought
Customers who viewed this item also viewed
From the Publisher
Unlike other books that focus exclusively on the science of estimationincluding rigid modeling techniques and continuous feedback loops that are not cost effective to most organizationsthis unique guide offers practical, tested, hands-on advice for estimating software development costs in the real world. It is written by the award-winning author of Code Complete.
Key Book Benefits:
Delivers practical insights about a critical subject too-often obscured by academic jargon Two-color graphics present mathematical information in an easy-to-understand format Provides specific practices that can be used immediately by any software development organization Features numerous, to-the-point tips about the estimation process, as well as individual steps to creating successful estimates
About the Author
Steve McConnell is recognized as one of the premier authors and voices in the development community. He is Chief Software Engineer of Construx Software and was the lead developer of Construx Estimate and of SPC Estimate Professional, winner of Software Development magazine's Productivity Award. He is the author of several books, including Code Complete and Rapid Development, both honored with Software Development magazine's Jolt Award.
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
The first 4 chapters apply to everyone, and for the most part agree with everything the author has written. Below I've given some insight on each of these chapters. I've given a brief summary of the rest of the book below the 4 chapters, as they apply to enterprise (which is not what my use case is)
# Chapter 1: What Is an Estimate?
This chapter covers what a typical estimate should be. It introduces the concept that estimates aren't what you may define them as. The author claims estimates do not need to be accurate, they just need to be helpful. They are the foundation for meeting a target goal, and must account for "control factors" (which are just assumptions, and accounting for problems that can arise).
Overall this pertains, again, to enterprise software. Estimates in the context of software development companies have more emphasis on accuracy: they dictate the profit gained for the company and the satisfaction of the customer. I'll humbly disagree estimates are just foundations for creating control factors.
I would have liked it if the author focused more on assumptions and provided examples. Every second of time outlining assumptions and types of assumptions in a scope of work has done wonders for my projects. I could write an entire chapter on assumptions alone.
# Chapter 2: How Good of an Estimator Are You?
This was my favorite chapter. It starts out with a simple quiz and teaches a valuable lesson on how to estimate ranges for impossible tasks. I won't spoil the lesson learned here. I'll just say that the general exercise in this chapter is one I'll incorporate in teaching others how to estimate projects.
The chapter also touches on how and why developers underestimate effort, backed up with links to studies. A very helpful perspective from psychology.
# Chapter 3: Value of Accurate Estimates
Which is worse, going wildly over or under on an estimate? This is my second favorite chapter because it talks about how overestimating is more dangerous than you may think. It touches on more psychology topics such as Parkinson's Law and Student Syndrome. Look up both if you're curious to learn more.
# Chapter 4: Where Does Estimation Error Come From?
This chapter goes over some of the typical reasons project estimates are errant. Many of the reasons you'll find boring and obvious. Several I'd like to point out are defined in detail, and again a very helpful look into psychology of estimates: unfounded optimism by developers, giving "off the cuff" estimates, putting too much faith into silver-bullet libraries that "should work" - but developers have no experience with (hint: always, ALWAYS, go through a discovery phase with anything unknown)
# The Rest of The Book
Starting from chapter 5, and for the rest of the book, the focus changes to apply to large companies. You will learn about highly abstract means of estimating projects: implementing a multiplier based on estimated lines of code, the industry the project [such as aviation vs farming], and using generalized historic data from public sources to estimate projects. In my opinion this is not only useless for modern web/desktop software projects, it's potentially dangerously misleading. The abstraction is too great to apply to any project outside enterprise projects.
These chapters also bolster the idea of assigning tasks and risks arbitrary labels such as small, medium, or large. The whole process gets very abstract, very fast. If you look at the COCOMO II estimation model you'll get an idea of just how abstract this estimate will become. As an example line item, you might have "Platform Volatility" which adds "5% total risk" - and I'm left wondering "What does any of this even mean? How do you quantify platform volatility as 5%?" no one can pick this estimate up and understand it without the business analyst explaining it in depth. Estimates should be easy and intuitive. These are not.
The book goes on a tangent towards the end, discussing schedules and even devoting a sizable chunk to the sole act of presenting an estimate to an executive. I do like the author referenced another favorite book of mine, "Getting to Yes," but these chapters feel out of scope of the book's goal.
Overall I'm happy with the first 4 chapters. Because of my specific application of web/desktop software development outside of enterprise, I wasn't happy with the book itself. That's not the author's fault, however. I still feel 3 stars is accurate even if that were not the case. I've gained much more knowledge from other books on the topic and free resources online.
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.
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.