undefined | Better HN

0 pointsrdtsc9y ago0 comments

> I'm so annoyed by the push for metrics at my service oriented company.

I saw it here on HN, from someone else and I remembered these quotes:

1) Just because it can be turned into a number, doesn't it mean that it should be.

2) Just because something has already been turned into o a number it doesn't mean it is important.

Usually managers will want to turn everything into a number. Number of tickets closed per iteration cycles, numbe of issues opened, number of lines written, number of comments per number of lines and so on.

Because they think those give them a deep insight into the team dynamics, and it makes their job more justifiable because they can use those "statistics" and present them to their manager instead of say wave their hands and say "yap it's fine, we shipped this feature, found some bugs, fixed them".

0 comments

3 comments · 1 top-level

mikekchar9y ago· 2 in thread

I have a very controversial opinion on this subject. Do not measure anything unless you know exactly what you are going to do with the measurement. To be fair to me, I stole this opinion from Tom DeMarco's books, but I'm often surprised at the kind of negative reaction I get when I bring it up.

Measuring things has a kind of Heisenberg principle. It is almost impossible to measure something without affecting how people operate on the thing your are measuring. So while you may get some benefit from your measurement, you are throwing something else completely out of control.

Just the act of measuring something can freak people out. Sometimes measuring something will cause people to unintentionally game the measurement. Sometimes the mechanics of measuring interfere with the operation that you are measuring. Sometimes your measurements are used to justify actions that are completely unjustified.

You must measure to control something, but you must measure the absolute minimum that you need to control it. If you find a way to control something with less measurement, you should usually switch to that method. Once you have achieved the goal of the measurement, you should discontinue the measurement.

rdtscOP9y ago

I agree

> but I'm often surprised at the kind of negative reaction I get when I bring it up.

Because they assume you are trying to hide or obscure something. "Why wouldn't you want more 'visibility'?" kind of stuff.

Then if you explain, unless they completely trust your reasoning, they think "Oh this is just a rationalization".

Moreover, over time metrics, and processes, and rules just accumulate. Every time anything bad happens -- new rule and some new metrics get added. Sure after a while they are ignored, but they are still there. Then nobody wants to be the person to say, let's clear the table of these unused rules and metrics let's have less.

mikekchar9y ago

One of the biggest issues I've run into is that people honestly don't believe that measuring will change behaviour. They feel that "Let's measure this just in case we can use it some time" is a good strategy. I can't tell you the number of times I've had the following sort of conversation with a developer:

"This story is not finished. It doesn't work at all".

"I know, but my estimate was 2 days and I've already worked 3 on it. Can't we just add another story to do the things that aren't finished? We're already taking a lot of criticism for being slow. I don't want to let the team down."

Then you have a finished story called "Add login to system" and an unstarted story called "Fix problems with login". The stake holder sees the list and says, "We can live with a few problems with the login system as long as the core functionality is there. Let's ship!"

But... nobody wants to admit that login doesn't work at all so they look the other way...

Absolute craziness that would be avoided if completion times were not measured.

j / k navigate · click thread line to collapse