Measure twice, scoop once
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. That’s significantly less than what we had been making. Each day our morning coffee is consistently perfect. (A pound of beans goes a lot farther 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, 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.
Z Trek Copyright (c) Alan Zeichick
On the other hand, measuring productivity by any given metric has a tendency to push people to maximize that metric, which may not actually mean maximizing productivity. That doesn’t mean you shouldn’t measure, but be judicious, and include multiple measurements.
I do feel like I need to say that any metric that includes lines of code is probably flawed; I just don’t think it tells you anything useful.
I have had this idea that you can’t manage if you don’t measure, rubbished pushed at me by bean counting senior managers for many years.
If you can’t tell it gets me a little hot under the collar ?. I’ve yet to find some/any aspect of my developer’s activities that can be measured that tells me anything useful about
their productivity. Taking the lines of code example, I give my best developers the hardest jobs. They produce the fewest lines of code but they solve the hardest problems.
Would I swap them for the guys punching out the easy stuff, not likely!! My developers aren’t measuring out 75 grams of coffee beans each day. It is not a production line.
They are solving problems that at the beginning we often have no idea where to start. Or they may spend a day finding a bug that requires 2 lines of code changes. Very unproductive!!
IMHO this sort of measurement is the totally wrong tool for the management job.
Having had my dummy spit I would be interested if somebody has a metric that is reasonably easily measured that is truly useful in determining a developer’s productivity.