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.


  • mattvanhorn

    March 26, 2012 at 4:40 am Reply

    Good post. I love the term “weaponized metrics” and will be bringing it up soon in my company.

    I actually like gathering metrics, they help let me know how I’m doing. I measure code duplication, design flaws, complexity, test coverage, velocity and a few other things.

    I do hate giving those number to management to be used as a weapon against me, though.

    (I also blogged on this stuff at: http://www.mattvanhorn.com/2012/03/22/carrots-and-sticks )

  • Anonymous

    April 11, 2012 at 8:32 pm Reply

    I strongly support the use of metrics as long as they’re providing valuable information into understanding the overall health of the project. I also think that people tend to hide behind the Agile wall, looking up excuses for what essentially is poor adoption of agile practices in planning / measurement — and that the project will take as long as it takes, “how long is a piece of string?” is something I often hear. No so, given a target / goal / deadline, a backlog can be generated up-front and be used to produce useful metrics.

    I recently posted white paper on the use of metrics for effective defect management, interested in your take on this:

  • David Koontz

    January 5, 2017 at 8:39 pm Reply

    You would like Jay Packlick’s slide deck on Metrics that matter. He plots the metric on a grid of X-asis Potential for Evil; Y-axis Potential Value


    • Rich

      January 26, 2017 at 11:43 am Reply

      That was awesome, thanks.

Leave a Reply