Weaponized Metrics

Software teams hate metrics. They don’t like to estimate work. They don’t like to tell you how much progress they have made. I remember my first “team” project. PM asked me to estimate how long it would take me to finish a task I had never done before on a platform I was new to. I replied that I thought it would take me about 1 week. PM was furious, ya know, Jack over there could have that done before noon. You software developers are all alike, padding your estimates. And so it went the whole project.

To software developers, metrics are like uranium. It is a dangerous substance, waiting to be converted into a weapon, easily used by management to destroy the team’s morale, and worse, productivity.

Here are three insurmountable problems with software metrics:

1) There are no units of measure. Software output is working capabilities. The the input is developer time. Most metrics are output over input individually or in aggregate. Problem is there is no unit of measure that unitizes software output. There is no easy, repeatable way to simplify the work of developing software into reasonable units of measure.  Martin Fowler said this.

2) Software “raw materials” are infinitely variable. For any problem or working capability there are any number of variants in the way it can be constructed. Coding Standards, design patterns, architecture decisions – reduce this from infinite to merely myriad. The mere selection of standards, patterns and architectures does not produce measurability.

3) Familiarity is a bigger factor than human capacity. Even if I could create standards of output based on the design decisions I have made, The predictability of the input required depends more on the familiarity of the practitioner than on his raw capacity. Of course familiarity develops over time, and it becomes predictable over time, but virtually every project starts with the staff in a state of some level of unfamiliarity and therefore unpredictability.

Software practitioners have learned over time that management can quickly weaponize metrics. Most hem and haw about giving estimates and for this reason. The agile community has created a metric with “arbitrary” units of measure as a way of creating “safe” estimates. Those that cannot be weaponized. If I give you real estimates, based on my honest thinking, and I own the risk of missing work, or my mistakes. If I don’t deliver, I am labeled a slug. If I time to account for that risk I am likely to be accused of “sandbagging” or padding my estimates.

Software practitioners have learned over time that if you hand the boss or customer a stick, he is as likely to beat you with it as anything else.