During a presentation on software metrics, I asked the audience to estimate the distance from New York, NY to Sante Fe, New Mexico in Kilometers (they were asked not to participate if they already knew the answer), and I asked them not to do any conversions in their head before giving their answer.  For those of you reading in other countries, we use miles to measure long distances in the USA, so kilometers is a unit that we don’t have much experience using.   The answers to the question were all over the place with most of them being overestimates of signification magnitude, double or more.  Then I asked the audience to estimate the distance again, but this time, they were to estimate the distance in miles – a unit they were all very familiar with.  These estimates were much better with all being less than 20% away from the actual distance.   Some were so close to the actual distance that they were essentially accurate.

Why were the estimates in miles significantly better than the estimates in Kilometers?  The reason is that the attendees all had significant experience in the unit of measure.   From the time they were little kids, they’ve been measuring distance in miles when they travel.  When they were in school, they used maps with a legend in miles.  When they drive to distant locations that they’ve never been to before, they use roadmaps with a legend in miles.  The odometers in their cars are denominated in miles.  Over the years they’ve built an historical database of locations, distance, and time that they can use to infer good approximations from incomplete information, like what’s the distance from New York, NY to Sante Fe, New Mexico.  This is possible when you have a familiar unit of measure and when you have knowledge of the distance to other locations that you can use to infer the distance to the unknown destination.

This example demonstrates how units and measures begin to have more meaning when we are familiar with them and use them regularly.  Most here in the US would be confused if they hopped in a car with their friend, and their friend said, “We’re going to take a 150 kilometer drive to my college friend’s house for a short visit.”  We would be clueless about how long that would take.  We’d be wondering if this would be a trip requiring an overnight stay.  Should we cancel evening plans?  It’d be disorienting to us.

Benefits

Metrics can help in the following ways:

• They give us a better, more accurate way to estimate our projects.  When the project completes, the actual values can be used to improve future estimates.
• They connote meaning when we all use the same unit for size: how many people are required to staff the project? How many defects can I expect to find? How long will it take?
• They improve monitoring and control of the schedule when actual values are compared to the estimating assumptions.  Consequently, status is more objectively reported.
• They give us objective criteria for making release decisions based on quality.  They tell us when done is done.

Summary

These benefits are all possible if we take a disciplined approach to using software size metrics.  The challenge to being successful with metrics is the ability to stick with a disciplined approach.  Too often discipline is a casualty of intense pressure to hit the date on software projects, but if you give this an earnest try, you may find it easy to be disciplined as the benefits are tangible, powerful, and immediate. 

In the next installment in this series I plan to develop the benefits more through example.