People are taught that when you want to achieve something, you must first set goals. And those goals must be measurable. If you wanna lose weight, set a goal of losing so many pounds in a certain amount of time. If you wanna get good at the piano, you must practice so many hours for so many days a week.
What I’d like to argue is that your goals should be based on something that isn’t measurable. If you wanna lose weight, adjust your life style. If you wanna learn to play the piano, find something fun to play. By setting your goals on something that isn’t measurable, you will shift your focus from gaining an objective value (quantity) to a subjective value (quality) in which only the subjective value will bring true contentment.
Goals and Quality
The difference between goals and outcomes is tied to the difference between quality and quantity. Quality is subjective, quantity is objective. If you ask somebody how they would improve the quality of the system, what they would give you is subjective opinions like “improve the interface”, or “make the code more readable”.
If somebody tells you that in order to increase the quality of a system you must increase a number of something, then they are not talking about quality: they are talking about outcomes or strategy.
Quality Isn’t Measurable
Trying to measure quality is impossible. The only thing you can measure is outcomes from the improved quality of the system.
In the software industry, one measurement of “quality” is code coverage. I’ve already gone over why measuring code coverage is a bad idea in When To Stop Looking at Code Coverage – Goodhart’s Law. However, high code coverage is usually an outcome of a system that has high quality.
Our software team uses Test Driven Development (TDD) to help ensure that we don’t add bugs into the system over time. The tests don’t improve the quality of the system. We use them to assert that certain expectations on the system don’t change. We could be writing very bad code that is very inefficient, but at least we know we haven’t introduce any bugs.
So code coverage isn’t a measurement of quality. It’s a measurement of something we did to help maintain/improve quality. Our goal is to make highly usable/scalable/maintainable/extensible software and code coverage is a strategy to do just that.
Nomological Networks
Should we still measure anything when trying to achieve a goal? Absolutely! Just remember, any measurement by itself should not be used to validate your goal. For example, measuring how much time one practices piano is a useless measurement if the only thing that was practiced was scales.
One way to use measurements to help assess quality is by building a nomological network of cumulative evidence.
A nomological network (or nomological net) is a representation of the concepts (constructs) of interest in a study, their observable manifestations, and the interrelationships between these.
Wikipedia
When creating a goal, like learning to play piano, a nomological network is a collection of observable manifestations (like total time practicing scales per day, total time practicing songs, ability to read notes in different clefs, etc…) and how these together help achieve your quality based goal. In his book The Parasitic Mind, Gad Saad introduces the concept of building a nomological network to build a bullet proof case for a truth:
“The objective would be to build a network of cumulative evidence stemming from widely different sources, all of which serve to construct the final jigsaw puzzle”
Gad Saad, The Parasitic Mind
Once you create your quality based goal, create a list of measurable actions or to/dos that you think will get you to your goal. Make the list as big as you can. This is your nomological network. Once you start on your goal, keep reassessing you list. Over time you’ll find that some measurements that you have in your list aren’t helping you achieve your goal. One will have to keep accessing the construct validity of each item in your nomological network. You will have to continually judge your nomological network items.
Human Judgement
The best way to really assess your goals is by human judgment. No machine or measurement can tell you quality, yet. The only entity on earth can can assess quality is a human.
In software development, the best way to achieve quality is by peer review. For our team, code that is checked in, is reviewed by at least two people. This is true for everybody, even our most senior developers have their code reviewed. We’re all human and humans make mistakes. We’re also a lazy species and self discipline can be difficult in the best of times. Having other people review your work is the best way to improve/achieve a higher quality.
I believe America’s founding fathers knew this when building our judicial system. Judgements in court are not made by measurements but by humans. A smoking gun doesn’t always prove guilt.
Only a nomological network of cumulative evidence with human judgement can bring us the best quality outcome within court.
Overview
Goals should be quality based. Since quality can’t be measured, one will have to use techniques like nomological networks and human judgement to gauge if one is achieving their goal.
LongLoft - Code Writer 