If you don’t measure, you don’t know how you’re doing. You don’t know what works and what doesn’t. You can’t figure out what to fix. And you can’t determine if your fixes actually work.

Or, as the well-known but oft-ignored saying goes, “You can’t manage what you can’t measure.”

Do you make coffee? Every morning I make a pot at home. For many years, I’ve scooped out the coffee until it looks about right. Most mornings the coffee tastes good. Some mornings it’s incredibly delicious. Some days it’s too strong. Some days it’s too watery.

That changed in September, after I read an article in the New York Times, “Tipping the Balance for Kitchen Scales.” The author, Farhad Manjoo, uses making consistently delicious coffee as one of his anecdotes. He explained that if you use volumetric measures (like a scoop), you’re not getting a consistent amount, due both to variations in the density of the substance as well as in the accuracy of eyeballing the quantity.

Following Mr. Manjoo’s advice, we purchased an inexpensive Oxo digital kitchen scale. I tried scooping out coffee the old way and then measured the results. The average was around 120 grams, which made pretty good coffee—but there could be a 20-30 gram swing. Even so, 120 grams wasn’t bad.

Then we started experimenting. 120 grams. 110 grams. 100 grams. 80 grams. 70 grams.

It turns out that my family loves the coffee when we use 75 grams of ground beans per pot, significantly less than what we had been making. Each day, our morning coffee is consistently perfect. (A pound of beans goes a lot further too, yielding 6.0 pots instead of 3.7 pots.)

Put down the coffee scoop and open your development dashboard. How efficient are your architects, developers, designs, testers or managers? Do you know? Have you measured source lines of code created per day? Analyzed function points? Looked at defects or security flaws per KSLOC? Counted the requirements added or changed per iteration? Elapsed time per defect remediation? Variation from time or cost estimates per feature? Time spent on non-refactoring rework? Developer time spent on non-development activities?

There are a gazillion metrics specified by ISO and CMMI, as well as other best practices widely known in our industry. Do you use them?

You can’t manage what you don’t measure.

If you don’t measure, you don’t know what is working well and where you need to improve. If you don’t measure, you don’t know if your fixes are making things better or are making things worse. If you don’t measure, you can’t drive toward consistent performance and consistent delivery.

Best of all, as my caffeine experience showed, measuring not only makes the coffee more consistently delicious, but less expensive as well.

Alan Zeichick is editorial director of SD Times. Read his blog at ztrek.blogspot.com.