Meaningless Metrics Make More Mischief

There is something strange in the world. That’s because people are full of “easy” solutions to problems. When I’m President was will be over in a day, that sort of thing.

International politics aside, this simplistic thinking has invaded the world of tech too. Think about the interview process and how broken that is in tech. Rather than working out who it is best to employ we will simply find out which developers are at best mindless trivia recall sessions. These are easy to measure, so we use that as our system.

To rate our current cohort of employees we do the same. We look at what we can measure, rather than what should be measured or what is effective. That translates to (in various companies) lines of code, story points, pull requests merged or bugs closed. So in comes our new arrival, tokens consumed.

But, hey, it’s all so much easier counting things than thinking, isn’t it?

Every Generation Invents Its Own metric

When I first started developing software, there were still people who believed writing more code meant you were more productive. As well as developers who thought that producing great code was a good thing to do (remember those days, because they aren’t coming back).

Let’s make this real for you. I’ve spent weeks deleting thousands of lines of duplicated code (and replaced some with better ones), and fewer lines can represent far more value for the business.

Although we all know that the best code is that which you never write, it isn’t appreciated by the business. Nobody cares that you are making things better. Nobody cares that we will be able to push features faster in the future. Put simply, nobody cares.

They’re measuring you according to metrics that fit their narrative, and it makes almost no difference what you actually need to achieve or what would be good for the company.

The False Metrics

Story points (and their annoying cousin t-shirt sizes) were supposed to help teams estimate uncertainty.

They became key performance indicators, because we could then measure how many story points you’ve completed in any given sprint. The estimation tool transformed into a productivity target.

The predictable result came, and developers subconsciously inflated their estimates and avoided work that didn’t “score” well. Technical debt, documentation, mentoring and debugging suddenly become second-class citizens because they don’t produce attractive numbers.

Goodhart’s Law isn’t new:

When a measure becomes a target, it ceases to be a good measure.

Software development seems determined to rediscover this every few years.

Equally, I’ve worked in teams where people proudly announced how many pull requests they’d merged that week.

It sounds impressive until you realize one developer split a single feature into twelve microscopic pull requests while another quietly delivered a complex architectural improvement in one.

Which one created more value? Who knows. Again nobody cared.

Organizations talk the talk about optimizing metrics around pull requests and then add reviewers, ceremony and rules that make actually merging a pull request more and more problematic.

The metric became the objective, but then again doesn’t it always. I was going to mention the old metric of lines of code, but that seemed out of date in 2026. Then I remembered what was actually happening in my company.

Enter AI

The latest obsession is token usage. We are measuring dollar cost, individually (and per team) against lines of code and pull requests.

How many prompts did you use?

How much did the company spend?

How much code did AI generate?

I use AI every day. I think developers who refuse to learn it are making a serious mistake. AI is a productivity tool in much the same way calculators changed mathematics, it lets us spend more time solving problems instead of performing repetitive work.

But counting tokens tells us almost nothing.

One developer might use AI to generate boilerplate code.

Another might spend exactly the same number of tokens exploring architectural trade-offs that prevent six months of technical debt.

The invoice is identical.

The value isn’t.

The Things That Matter Are Awkward To Measure

How do you measure the developer who notices a security problem before release? Or the one who quietly mentors three junior engineers? Or the person who simplifies an onboarding guide that saves every future hire two days of frustration? Or the engineer who prevents a production outage that nobody ever hears about?

Those contributions rarely appear on dashboards.

They don’t fit neatly into quarterly reports.

Yet they’re often the difference between successful engineering teams and dysfunctional ones.

Management loves certainty

If your metrics encourage developers to optimize the numbers instead of the product, don’t be surprised when that’s exactly what happens.

Yet management still loves it. It’s easy to measure so that’s exactly what they do. They measure easy outcomes rather than complex activity that involves thought.

Which is the definition of bookkeeping, I’d say.

The software industry doesn’t have a shortage of dashboards.

It has a shortage of metrics worth looking at.

Perhaps that’s because the most valuable work in software engineering is usually the hardest thing to count.

And that’s why we all become important book keepers.

About The Author

Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper.

The Secret Developer doesn’t actually know what a bookkeeper does.