It’s practically a tautology: to produce the desired effects, the causes of those effects must be in place. Yet it can be easy to spend less time ensuring that the causes of quality are nurtured and more time reacting to the inevitable negative consequences of poorly-crafted code. Causes and effects are often separated by much time and space, so a reactive approach will always have you locking the barn door after the horse has already bolted.
Healthy Organizations Do Things Differently
It’s not necessarily the case that organizations that have lower quality output value quality less; it’s that they apply pressure to the wrong parts of the system.
A personal anecdote illustrates this well. In early 2015, I would reach for a sugary soda when I was feeling fatigued and it would help: for a little while, my energy would increase and my mind would sharpen. Then, in June, after displaying all the classic symptoms, I was diagnosed with type 2 diabetes. After doing some research and realizing that the disease can be put into remission through diet and exercise, I ditched the soda and hit the gym. And then, a funny thing happened. My fatigue, which I had been living with for so many years without realizing it, vanished. In a perverse irony, the soda that I had been reaching for to deal with my fatigue was one of the root causes of my fatigue.
The point is that once I understood the systems of my body better, I was able to target the correct places in the system to make a change. I find this holds true in general: not only do healthy software organizations do things differently, healthy people do things differently, successful students do things differently, and people who manage their finances well do things differently. And the difference is this: when they want to make a change, they end up targeting the correct place in the system to bring about that change.
Managing the Invisible
Managing software is difficult and here’s one reason why: you have to manage invisible value. A developer spends their time engaged in various activities during the day. Let’s split them into three categories:
- direct value (such as writing code for a feature to be released immediately)
- indirect value (such as improving test coverage or refactoring code)
- waste (such as playing find the invisible cow or implementing an over-engineered solution for the fun of the technical challenge)
So, somewhat counter-intuitively, more attention should be given to measuring whether the causes of quality are present than to measuring the ultimate, final goal of quality (such as the number of bugs). For example, providing developers opportunities to learn more about their craft will go a lot longer than rewarding developers for not producing bugs (which is also known as “rewarding things a dead man can do”).
Wyatt’s Rules of Software Quality
I hope this blog post has given you something good to think about! If you wish to read more, this post is part of a four-part series on software quality: