on 9 March 2007
At the beginning the tile put me off, as everybody else I though "I know how to estimate, I don't need this book". Well, I was trying to enhance my estimations and I decided to have a go on it.
At the beginning of the book you are bombarded with stories about how wrong estimations can be and presents you with tons of statistics, you start to think "hey! These guys didn't know anything about estimations!" but when you continue reading I started to realize that their estimations are based on pillars that I am also using... scary. At this stage I was more interested on the book.
The book is full of tips and descriptions about the different areas that you must consider on your estimations, taking into account size, effort, schedule and tons of planning parameters. This book is a recommended one to have on your bookshelf as you cannot remember all these things in one go. Another interesting area of the book is the negotiation skills, who wasn't involved in a situation where your boss tells you to introduce hundreds of features within the same timeframe? Well, this book helps you to deal with those situations.
The only reason why I don't give it 5 stars is because of the amount of stats, that actually cuts the flow of the reading on every page. But trust me, you won't regret.
on 4 December 2013
Good book as per Steve McConnell's other books. I have both Code Complete 2 in paper and Kindle versions.
Both are great reading when I'm travelling and I tend to read the Kindle version as both books (in paper) are weighty tomes.
One thing that's a bit odd with this book is that there's no Table of Contents on the Kindle Version. Hence -1 Star.
In my kindle version, there's sections Cover,Software Estimation..,Welcome,Acknowledgements,Equations,Figures,I,II,III,A,B,C,Bibliography,Steve McConnell,Index,About the Author,Copyright,Location.
In my paper version, on page iii, there's contents at a glance, and on page v there's Table Of Contents.
I wonder if this was missed in the conversion?!
on 31 October 2008
Steve McConnell gives a superb overview of 30 years of software estimation practices. The book is useful for both managers (to establish how well the company estimates software projects) and practitioners (with many pointers to literature with more in-depth discussions).
I liked in particular the clear distinction the book makes between estimates, targets and commitments. Also, the political minefield associated with estimates is discussed well. Another area which I liked very much is the emphasis on clarifying the assumptions on which the estimates were based.
Having said this, the book could be even better if it would explore deeper the following topics:
1) Who are permitted to estimate? The book loosely mentions that the best estimators are those who will do the work. True, but this is a minimum requirement.
2) What exactly is estimated? It takes about 20 chapters before the author mentions that most of the rules and benchmark material refer to the design, construction and testing of software (excluding requirements gathering and project management). It would be helpful if the scope of the software development would have been described more precisely from the beginning
3) A software development project most likely will be embedded in a larger project intending to deliver a business change. The book would have benefited from exploring the relationship (regarding effort, cost, schedule) with the components of the larger project
4) The book does not mention the relationship with benefit estimation. Also, today's software engineers are expected to be able to speak the language of finance, and the book would have benefited by discussing the time value of money, capitalization etc.
Nevertheless, this is a must buy for software engineers and managers who are involved in project estimation.
on 12 August 2009
Within the context of a response to a call for tender, I was given the 'not-that-trivial' task of writing a piece on how our company approached software estimation. I must confess that I had never thought of it as a process. Therefore, I bought the book to get an overview of estimation techniques and practices.
I must admit that I did not throw my money away. McConnel's book is a step by step approach to software estimation based on a collection of facts and study results. He drives you through those techniques in a progressive way and compiles a list of tips that everyone shall keep handy.
The book covers major estimation techniques as well as provides directions as to when to apply them to ensure that one gets the most accurate results. The most important idea that the book conveys is that one shall always try and find something to count in order to compute and not to guess.
To make a long story short, this book's a must have.
on 30 March 2012
McConnell's books include "Rapid Development", a title that is still the best book on software development techniques that we would now call "agile" - although the book predates the term by several years. "Software Estimation" expands and updates the material on estimating from the earlier book.
McConnell's book starts with some simple but often mis-interpreted definitions of the difference between estimates and targets. Am estimate is (usually) a date-range during which a piece of work is finished; a target is a date commitment to meet this. The emphasis on having a date-range for an estimate has echoes of Demarco and Lister's work.
He also provides useful definitions of large, medium and small projects. He defines large as having more than twenty-five technical staff, with project duration in excess of twelve months; small as having five or fewer staff and medium as those falling in between.
In addition, he categorises project type as either sequential or iterative in terms of whether most of the requirements are fixed early in project (sequential) or whether most are defined after some construction has started (iterative); those techniques defined as agile, such as XP, Scrum and DSDM, fall into the iterative category, while those such as RUP and plan-driven fall into the sequential category.
McConnell goes on to describe various different estimating techniques and shows there applicability to the size and the type of project.
* expert judgement - little more than guesses by subject-matter experts;
* decomposition - breaking down functionality to small, estimable chunks;
* analogy - getting estimates on a new project by comparing actual figures from a past project;
* proxy - using other measurable items such as function points or story points as proxies for lines of code;
* group - allowing a group of experts to estimate and negotiate a commonly-agreed figure;
* tools - using software-based tools to generate estimates.
In addition, he describes how to use two or more methods in parallel in increase the confidence in the estimates.
McConnell chooses to base most of his book using lines of code (LOC) as a standard. This measure has fallen out of popularity, especially in agile estimating circles. The author makes a robust defence of this, making the points that:
* it is a measure that it is common to all software projects;
* there are associated historical effort figures on which to base estimates;
* that different software languages will have different productivity factors that need to be accounted for - factors which the author lists in the book.
He advises starting with LOC if nothing else is available - other standards may be chosen as long as they are countable and effort-based historical records are available for which to base the estimates on.
Some interesting findings stand out:
* for a 10% reduction from the nominal schedule, you need a 30% increase in staff numbers;
* it is not possible under any circumstances to reduce schedule by more than 25% from the nominal;
* as a rule of thumb, the minimum schedule time can be calculated by doubling the cube-root of the number of estimated staff-months.
McConnell also describes estimating using story points. This technique, popularised by highly-iterative agile methods such as XP, is when the team decompose the requirements into small elements and then use an arbitrary scale of estimates. For example a small requirement may be "one point", whereas as larger one may be "five points." Initially, converting the arbitrary value to an effort estimate is performed using historical figures by analogy, but as the project progresses, subsequent estimates are performed using historical results from the previous iterations.
The book is recommended as it summarises and updates all the techniques for software development estimation for all types of projects. However, it is especially useful for practitioners on larger projects, as other literature in this area has not kept up-to-date with recent technologies and techniques.
on 11 November 2011
Steve McConnell gives a good and thorough overview of software estimation practices and especially the very critical aspect of working with stakeholder expectations, i.e. lowering them to a reasonable level based on experience and hard data.
An absolutely recommendable book for those that estimate, whether developers, project managers or other management roles in software projects.
on 17 March 2011
This book is a classic, and rightly so.
I found it really, really useful at estimating software development tasks and I use the formulas in the book all the time.
I thoroughly recommend it.