Red Squirrel Reflections Dave Hoover explores the psychology of software development

[Previous entry: "Mind Your Metaphor"] [Main Index] [Next entry: "Reading O'Reilly's Red Squirrel"]

Accuracy and Precision
Tuesday, October 21, 2003

Will I ever stop blogging about Steve McConnell? What can I say, I'm becoming a fan. Though I don't agree with a few of his ideas about software development, there is a lot that I do agree with. There is a lot of wisdom in his books. I enjoyed this sidebar (Rapid Development, 173) so much on the train this morning, I felt compelled to transcribe it here...

"Accuracy" and "precision" are related but not identical concepts, and the difference between the two is important to software estimation. Accuracy refers to how close to the mark a measurement is: 3 is a more accurate representation of pi than 4 is. ... Precision refers to how many significant digits a measurement has: 3.14 is a more precise representation of pi than 3 is.

A measurement can be precise without being accurate, and it can be accurate without being precise. 3 is an accurate representation of pi, but it is not precise. 3.3232 is a precise representation of pi, but it is not accurate. Airline schedules are usually precise to the minute, but they are not very accurate. Measuring people's heights in whole feet might be accurate, but it would not be precise.

In software estimation, false precision is the enemy of accuracy. An effort estimate of 40 to 70 man-months might be both the most accurate and the most precise estimate you can make. If you simplify it to 55 man-months, that's like representing pi as 3.3232 instead of 3. It looks more precise, but it's really less accurate.

Shortest-possible software schedules are achieved by creating the most accurate estimates possible, not the most precise. If you want to achieve maximum development speed, avoid false precision.

Replies: 2 comments

Taking the need for accurate estimates as a given, the best way to make estimates more accurate and precise is to limit estimating to the near future. For example, XP iterations are usually 2 weeks, and Scrum sprints are usually 1 month. Estimating in general is much more accurate at these levels than, say, estimating over the next *year*.

Posted by Darrell on 10/23/2003

"Rapid Development" is my favourite of his books. As you say, it's chock-full of good advice (from a practioner who has read the theory).

The later books like "After the Goldrush" tend to be less pragmatic and more preachy. In terms of the agile manifesto, I get the impression he values the things on the right (processes, documentation, etc.) too much and does not pay enough attention to the things on the left (individuals and interactions, working software, etc.). His promotion of state licensing of software engineers also raises my hackles.

However, "Rapid Development" is still a great book. I'd wager it's the best thing that ever published by Microsoft Press.

Posted by Christian Murphy on 10/23/2003

Powered by Greymatter