I hate METRICS!

So often I have seen metrics being introduced to improve the performance of a job/team/group/whatever! But all that happens is that people stop doing the job and start working the metrics!

[1]Goodhart's Law

[1] https://en.wikipedia.org/wiki/Goodhart%27s_law

Safety-related projects often have a requirement to achieve 100% code coverage. I've seen some where automation is used to generate the test vectors, and they are blindly accepted without verifying that the results are actually correct ("but we've got 100% coverage") - all that has been proven is that the code works as it has been written, not that it works correctly.

I was on a major cross-organisation project. The company doing the AWS side of things assured us that the tests for their stuff all passed.

One day I thought I'd look and see what they did... terraform validate

Are you implying that tying people's salary to a specific performance metric, might see people focusing on that metric rather than the actual Job at hand? Surely not!?! Who would do such a thing?

*cough*Everyone!*cough*

Every technical service manager loves metrics. Metrics is how their yearly bonus is calculated.

There is this multi-billion dollar, American company that introduced a metric which measures how long each ticket is sitting in "Waiting for Customer", "Waiting for the Tech", etc. To the eyes of the VP for Operations, "Waiting for Tech" is really bad (for the company) because it would make it look like the tickets are not being looked after. So the challenge was handed down to the technical support managers to bring those minutes down.

One ingenious way was for the tech handling the case to send an email to the customer. Internal system will immediately flag the status of the case to "Waiting for Customer". Another method is to send RFI emails when it is night time (for the customer) or approaching beer-o-clock on a Friday. No matter how good the information the customer have provided, the tech agents always will always find a way to send the case into Waiting for Customer.

At the end of the day, all the executives got their bonuses at the cost of customers' experience.

"At the end of the day, all the executives got their bonuses at the cost of customers' experience."

Indeed, some years ago, the Veritas basic support was absolutely useless, pushing every customer to buy premium which was the only one being useful.

The basic one had a very particular way to make sure everything stayed in customer info wanted:

1- ask logs X

2- ask logs Y

3- reply some gibberish and request some more logs

4- go to step 1

How can you beat that ? We went nuts about this ... They were simply bots coding a loop.

Please see the British education system

At one company, I wrote a dashboard that showed time by engineer. Everyone soon got hold of it and just fiddled the missing time.

Another, the bosses loved to see ticket stats. Some of us had low stats as we got the "stinkers" that no one else would cover. One person used to get really high ratings for one simple reason. The company had ancient old print servers - lots of them, and they would frequently fail, so a lot of tickets would come in very quickly. They'd grab them and then reboot the server and close the tickets. Overall time, around 10 minutes, number of ticket - almost a days work.

They hated it when I got rid of all of the old print servers and put a freshly commissioned cluster (repurposed old kit), just for printing. No more print calls after that.

We had problems getting kits to the shop floor due to component shortages. The bottleneck was in goods Inwards and inspection so they were given some "help" and part of the "solution" was a huge metrics board showing their processing rates against targets. Sure enough, the metrics got better and better, pats on the back all round - except kits still weren't getting to the shop floor due to shortages. Broadly, there are two types of components that come into the company - simple stuff, nuts, bolts, resistors, ICs, etc, that come with a CofC and need no inspection other than counting and checking in. Then there are more complex parts - PCB assemblies, amplifiers, filters and such - that have to be tested. In the time it takes to put a card in a rig and confirm it works you can book in a few thousand M3 nuts and resistors, so, to keep the metrics looking good, that's what they were doing - putting the hard stuff to one side and booking in the easy stuff.

You get what you measure.

We had a big metrics drive and I was told to get a metrics board up that the high-paid help could come and look at so they could understand what was going on. I knew this would end up sucking in tons of my team's time for little benefit, so I told the boss that I'd create a metrics plan so that everyone knew what was going on. We liked plans in the company, so he agreed. I knocked something up and then added a section called "Leadership Response" and asked the boss to work with his peers to complete it. 'What is it?" he asked. I said that we're creating these metrics for the leadership team to come and look at, so we need to know what they're going to do with them, particularly when things aren't going well. What are the limits at which they do something? What will they do? How quickly will they do it? What metrics should we capture to track their responses? Once he'd agreed all this I'd write it up and they'd get their own section on the board to show how well they responded to the metrics.

He couldn't really argue - it was a perfectly reasonable request. The metrics board never went up.

Office judo! Love it!

I'll have to remember that one.

I can get behind them if they actually are meaningful - but then they are often harder to interprete for the manglement. They, on the other hand, like strange, stupid, meaningless metrics. And then there's colleague who have no f'ing clue about statistics or data analysis, and pull definitions (to stretch that term) out of some nether regions - which then show "interesting results", but in the end are just tracking... something.

I need more alcohol.

And I am glad I am no longer part of that team. Should said person try to take over my team I'll just quit.

Worked in a company where the product was *really* buggy, esp late in the dev cycle when we were approaching release. Not a problem for management though. They'd review the bug list and reclassify most of the serious bugs as not so serious. That brought the metrics down enough so that we were good to go. We shipped on time and everyone got their bonus. Everyone was happy and no one got hurt. Except the customers.

Dilbert, is that you? I wondered where you'd got to, haven't seen you for a few days...

I managed one project where this approach was taken, as long as there was a documented work around a critical bug fix could be deferred. A month prior to go live there were 1500 documented work arounds plus as many unfixed less critical bugs, the system was completely unusable. They had effectively given up fixing bugs on the phase 1 delivery to start developing phase 2. I finally managed to get some focus by showing the senior stakeholder the huge paper file of workarounds every single system user was supposed to have on their desk and use every time a transaction failed. It amazing what impact telling a vendor they are about to miss a milestone payment can have. ALso because there had been no work done analysing root causes fixing 300 bugs fixed resolved the vast majority of work arounds, once the devs were allowed to take time out to really look at issues the system stability and usability improved hugely.

Several nuts wielding keyboards at my place of work. Clearly other people are more adept than me at solving errors in the live environment when I see this type of code:

...

try {

// Some SQL

...

// Throw exception if SQL failed

}

catch (blah) {

return SUCCESS;

}

...

return SUCCESS;

Ah ah, good one.

One day, I was admin of the main SMTP relay in a big company. I didn't know some idiot had coded it in a world widely deployed PC app, some thousands users.

This email system was always up as part of out world wide DC.

I happened to be quite ennoyed at hundreds of SMTP connections coming from anywhere that should be here, and which were creating havoc on the system.

Then I started to black list some clients, over and over.

After one month, a little midget came to me, explaining his issues: his apps was failing to issue orders. Me: yeah, why ? Him: we tracked it to SMTP connections failing. Me: then retry later if there is an error code. Him: hmmmm, we don't track error code, so all orders are lost. Me: AH AH AH, please go elsewhere, thanks.

Really no sympathy for nuts let loose in coding ...

A little midget you say? They're always worse than the big ones.

Worked for a company who outsourced some of their work to a very large, well known outsourcer. Their devs were expected to write 200 lines of code per day and were disciplined if they did not meet this goal. Thus, their motivation was not to write good, clean, extensible code but to write 200 lines of code regardless. Needless to say, it was the *worst* code I have ever seen in 30 years of professional development. It had every anti-pattern you could think of and a few I'd never seen before.

We took the code inhouse where our devs motivations were the exact opposite. The code was eventually refuctored enough that it started to improve but it took a *long* time to sort out the mess.

And logging -200 lines on a day would be a real catastrophe. Imagine you actually remove lines. That does not managerially compute.

I have actually been in the situation of refactoring the code from a previous (engineer) developer, and it was when my boss was monitoring LOC as a metric. I asked him if LOC was more important than bug reduction. After several months the code base was half the original size, and bugs had been reduced by nearly 90%.

That was when I learned my hate of metrics. I nearly didn't get a pay rise the following year because I hadn't hit my LOC target.

"it was the *worst* code I have ever seen". Please tell me you're not the comic book buy of your org!! LOL -->

Refuctoring. The art of taking existing code and fucking it up by hacking it to pieces, adding in large amounts of cut and paste code and introducing hundreds of new bugs, due to laziness, lack of knowledge, and complete disinterest in design principles.

Well... This EXPLAINS Bombastic Bob

another missed opportunity.

And what would have been wrong with Ticket Performance Statistics report for the boss then?

I think it's a bit of a rubbish acronym ... prefer PICNIC ... problem in chair, not in computer.