Software quality metrics: 3 to track instead of blame

Software quality metrics a non technical owner can ask for: errors per day, time to diagnosis, and how many people can explain the code. Why a blame field erases all three.

A steel assembly report asks for drawing, batch and date. It never asks who to blame.

Three numbers answer what you actually want to know when software breaks, and none of them is a name. How many errors the system threw yesterday, with the last fifteen days sitting next to it. How long it took, from the first error to someone saying where it came from. And how many people in your company can explain, in one sentence, what that part of the system does.

All three fit in a twenty minute meeting, you can ask for all three without reading a line of code, and all three get worse the day your first question after a bug becomes "who did this".

That question has an address. A manager decided to add a "person to blame" field to every bug report on his team, and one of his developers went to Stack Exchange to ask how to talk him out of it. The thread picked up 716 points, 29 answers and over 138,000 views. Almost all of it is developers talking to developers. I read it from the other side of the desk, because I used to be the manager who wanted the name.

I asked for the name of whoever broke it, and it cost me a company

Ask how many errors the system threw yesterday. No number in a minute means nobody is measuring.

My first company rented heavy equipment to construction sites, the kind of thing everybody was calling the Uber of something back in 2016. I hired developers without really understanding what they were telling me. I could not judge an estimate, I could not judge a delivery, and every Friday the sprint closed without the thing I thought was coming.

So I asked what felt like the most reasonable question on earth: whose fault was it? I believed the name would hand me back the schedule.

What I got back was silence. In the following meetings, problems stopped showing up early. They showed up the day before the deadline, wrapped in language that accused nobody. I had traded information for peace, without noticing that information was the only thing I was buying in those meetings. It took me close to three years to see it. The company died first.

Years before that I signed off on steel structures as the responsible engineer, including the assembly at the Interlagos race circuit in São Paulo. The non conformance report there had no blame field. It had a drawing number, a revision index, the batch of the part, the date, and what was done about it. The fitter's name showed up sometimes, and it was never the reason the document existed. The reason was finding out whether another part from the same batch was already hanging somewhere in the structure.

Software did not invent the urge to find someone at fault. Software just made blame very easy to record and batch numbers very hard.

The blame field erases exactly the data you need

The day a name becomes a required field, the bug report changes jobs. It stops being a record of what happened and becomes the opening of an internal case. From there, three things happen without anyone agreeing to them: the person who finds the problem thinks twice before filing it, the person who fixes it writes the vaguest possible cause, and the field fills up with whoever was on call instead of whoever made the decision that caused the thing.

The manager who creates that field wants something legitimate. He wants to stop being surprised. The field delivers the opposite, because surprise is a symptom of late information, and the field makes information late.

"But if nobody is accountable, nothing improves"

Half right. Clear ownership is mandatory. The unit of ownership is a piece of the system, not a bug. Owner of the checkout route, owner of the payments integration, owner of the pricing service: that is a name in a spreadsheet, it is enforceable, and it works. A name attached to one specific bug is useful for exactly one conversation, and it happens in HR.

The switch that changed my own meetings was dropping "who did it" in favour of "when did we know", the same way I stopped asking how long it will take and started asking what moves the date.

Number one: errors per day, with the trend beside it

When one person is the only one who can explain the screen that bills, the risk belongs to the company.

I have walked into a system that, as far as the person paying for it knew, was working fine. It was throwing somewhere near 400 errors a day with no alert firing anywhere. The owner was not careless. He had simply never been handed the number, which is also how the customer ends up reporting the outage before the vendor does.

Ask your team how many errors the system threw yesterday. If no number arrives within a minute, you do not have measurement, you have a feeling. And read the trend, not the single value. Ninety a day two weeks ago and 300 today tells you far more than 300 on its own.

One warning from someone who has seen the stage set: a health endpoint returning 200 without touching the database, next to a colourful dashboard fed by empty data, counts as zero. The instrument has to measure something that actually happens, and a report that looks far too clean for a codebase the team avoids opening is usually theatre.

Number two: the gap between the error and the words "found it"

Fixing is usually quick. Finding out where it came from is the slow part.

Take the last problem your customers felt and write down two timestamps: when the first customer was affected, and when someone on the team said "found it, it is this call". The distance between them is your second number. In a system that records nothing, that gap is guessing time, and guessing time grows with the size of the codebase.

This is also your technical debt thermometer in cash terms. Every undocumented patch stretches the gap a little, and the effect lands in next quarter's budget, when a tiny change arrives with a construction schedule attached. I have taken a request to change one pricing rule that turned into nearly a month of work, and none of that month was pricing complexity.

Number three: how many people can explain that code

Three in the morning, system down, and the one person who could explain what that file does no longer works there. This is the number nobody tracks and everybody feels.

Run the most boring inventory you can: list the five screens where money enters your company. For each one, ask who can explain what happens underneath. If three of them come back with the same name, and that name belongs to a single person, the risk is now the company's, not that person's. It is the same arithmetic as who the team they sold you really is, measured in heads instead of contract clauses.

This is where the blame field charges the highest interest. Knowledge spreads only where being wrong in public is cheap. When being wrong costs you a name in a form, every person hoards what they know as personal insurance, and your company ends up hostage to three people without ever deciding to be.

The contract model teaches the vendor not to measure

Part of this is not about your team at all. A fixed price with no continuity built in pushes a vendor to ship the shell: they know they are leaving, so they have no reason to make your system countable. Making it countable costs hours and never shows up in the Friday demo.

Buyers ask for what they can judge, and a pretty screen is what anyone can judge. That is why the vocabulary matters before signature, down to the terms every contract uses and nobody defines. And it is why our own rule exists: when the squad enters a system we did not write, the first two weeks go into measuring those three numbers before proposing any change. That is not generosity, it is the only way a ruler exists for the rest of the engagement.

What to ask on Monday

Three questions, in this order, none of them asking for a name:

1. How many errors did the system throw yesterday, and what was that number two weeks ago?
2. On the last problem customers felt, how many hours passed between the first affected customer and the team knowing the cause?
3. Which of our five revenue screens have exactly one person who can explain them?

If you have two developers and a product that charges nobody yet, this is early. Measure the first one and stop. And here is what these numbers do not do: they will not tell you whether the product is good, or whether the architecture was a smart bet. They tell you whether you can see what you are paying for.

Open your bug tracker right now. If there is a field for a person's name and no field for the hour the first customer was affected, you built an archive of blame instead of a management instrument. And if you still want the name, answer this one on your own before you ask for it: what were you going to do with it?