There are many metrics. Some are mainstream, some are measurable, some are imposed. Most can be gamed.
But there’s one that neatly aligns with quality — happiness.
In the last decades our industry has matured and developed several metrics to assess the productivity and quality of the software we maintain. Based on my recent experience, teams are adopting the four metrics proposed by Accelerate: delivery lead time, deployment frequency, time to restore service, and change fail rate.
But remember the days when a software developer was judged by the total lines of code they would write? Were you bad because your code has comments, descriptive names and proper whitespace? Were you bad because your language saves on boilerplate and you use its full syntax to write concise code?
Today, we laugh and dismiss that metric.
It doesn’t matter how many lines you write. What matters is code readability. That’s the goal. Then you find measurements that univocally contribute towards that goal. In that example, it would be more effective to measure the number of WTFs per day than the lines of code per dev. Ha ha, that’s just as silly! No one would dare use such an unconventional metric — and yet… it’s perfectly aligned with the desired outcome. More on that later, stay tuned.
Many conventional quality metrics
What about us testers? What metrics do we use? Oh, we have plenty of those:
Numbers… of bugs found (by us and the user), regressions, outages
Totals… of new tests, tests executed, testing hours, tickets rejected by QA
Percentages… like coverage, passed tests, flaky tests, ratio between code and tests
In my opinion, quality is value to some person, who matters.
Do you think your software will have quality if you maximise those metrics above? Maybe, at best. That’s a lot of effort for just a “maybe”!
Let’s measure the number of bugs found.
- We found 0 bugs. Do we have quality?
- Maybe yes, or maybe we are bad at finding them.
- We found and fixed 100 bugs. Do we have quality?
- Maybe yes, or maybe we missed 5 bugs that frustrated our users.
Fine, let’s measure test coverage. Everyone does it anyway.
- We have 20% coverage. Do we have quality?
- Maybe not, or maybe we covered just what matters.
- We have 100% coverage. Do we have quality?
- Maybe yes, or maybe our users still hate our software.
Just because a metric is conventional or popular, doesn’t make it right. Just as there are no best practices, only good practices applied in the right situations.
We all want one thing
No, it’s not that.
Some of the strongest and most important things in life we have trouble explaining them. Try to explain consciousness, or love, or happiness. It’s tough, but it’s so easy to spot it!
So let me propose an unconventional metric: happiness.
You: Feelings?! screeches in engineer noises
Me: Yes. Your software serves humans. They have feelings. And so do you.
The makers of software are humans. The users of software are humans. All humans have feelings. And all humans pursue happiness.
Yes, happiness is subjective, yet it’s easy to measure — it’s a yes or no question. And when people are unhappy, they are usually able to name their biggest pain. Ask them about bottlenecks, pain points, obstacles, and keep optimising your team’s happiness.
Remember Maslow’s pyramid of needs? Developers have their own needs too. The same way a person won’t care about art while they are hungry, a developer won’t care about quality while they are miserable.
Thankfully, the term “developer experience” is becoming popular. Engineers are now seen as people with feelings and needs, instead of a resource that codes in a basement if you give them enough coffee.
Once you have happy developers, they’ll put extra thought into their work, they’ll write more tests, they’ll actually use their software before shipping it, and they’ll listen to the users. In a word, they’ll care.
Nowadays software is everywhere. We use it only a daily basis. I’m sure you felt it too: the frustration of using bad software, the time you waste, the anger you build up.
Negativity and positivity are both contagious. If I’ve been trying to submit the same form for the last 20 mins, I feel sorry for the person who speaks to me exactly when the validation fails for the n-th time. Negativity spreads faster, so that person’s mood will be tainted by my interaction, and so forth.
Now picture a software written by happy developers that actually care. The software is a pleasure to use, you are in control, you achieve your goal, and it actually saved you time. You are at peace. (exhales) Namaste.
The world is so used to broken software that we sell “It just works!” as a feature, a competitive advantage over others. Imagine a salesperson selling you a car by saying “It moves!” — you wouldn’t be impressed would you?
So when people use good software, believe me, they will spread the word and the positivity to everyone around them.
Now imagine what we all can achieve if we are all happier and less busy because of the software we use.
When in doubt, optimise for happiness. Does doing X or measuring Y puts us closer to achieve happiness, for us and our users? If yes, then do it.
Oh, and on your next conference, if someone asks you what type of tester you are, after people give boring answers like “I’m a risk-based tester” and “I’m an ISTQB tester”, you can simply say “I’m a HoT tester!” 🔥😎🔥