If your team strives to build quality software, I applaud them.
If your team has created specific standards which ensure quality, they are in the top 15% in the world (based on my experience.)
But if your team recognizes that quality is always subjective, personal and political, then something amazing has happened.
Not quite there yet? Read on…See, quality is subjective, not objective. There is no such thing as objectively quality software, yet it’s a common fantasy most programmers and managers hold to.
A definition of quality is a statement about what a person values at a particular time.
Some examples:
- Novice users may value software which is easy to learn.
- Experienced users may value software which has many shortcut keys.
- Developers may value software built with modern tools.
- Managers may value software which ready when needed.
- Clients may value software which costs as little as possible.
Quality is also always political because we cannot make everyone happy all the time.
Instead, we must pick and choose who’s definition of quality we will use.
This requires negotiation, prioritization, and discussion between the various parties.
The first step to improving qualityThe first step it is to stop talking about quality in absolute terms.
Don’t allow your developers, users, clients, customers, managers, founders or sales folks to use fairy-tale language about quality.
After all, who could disagree with someone who states “We need to build good quality software.” That statement will get everyone’s head nodding, even though no one has any idea what it means.
It’s worse than that. Everyone will have a different idea of what it means.
Having different ideas about what quality means is more harmful than having no idea what quality means. When this happens, each team member will strive to produce software which matches their personal, unspoken definition of quality.
When you hear someone talking about quality is absolute terms, stop the conversation and ask who’s definition they are using.
Then teach them what you’ve just learned about software quality.
Then you can have a productive discussion about what quality means to the team, clients, users, and managers.
An illustration from gardening
When I was twelve I was a reluctant gardener.
Every year my father would order a dump-truck load of mulch to be delivered to the front of the house, near the road
Then he’d hand me a shovel and a couple wheelbarrows.
The algorithm went like this:1. I would shovel mulch into the wheelbarrow to fill it.2. I would push the full wheelbarrow 150 feet to where he was spreading mulch.3. He would give me the empty wheelbarrow.4. Goto Step 1
My father’s definition of quality was simple:1. Don’t spill the mulch on the ground when you shovel it.2. Have a full wheelbarrow to him about the time he was out of mulch.
For many reasons, I did not enjoy this job.
To make it tolerable, I created an additional definition of quality:1. Fill the wheelbarrow using the fewest number of shovelfuls of mulch.
My quality rule made the process more interesting and fun for me. it also made me feel in control of a situation I didn’t enjoy.
I thought I could add my rule to my father’s quality rules without any impact.
It turns out, that was false.
Counting shovelfuls don’t take much time, but creating heaping-huge-heavy shovelfuls did.
Moving heaping-huge-heavy shovelfuls without spilling caused me to work more slowly.
No matter how slowly I moved the heaping-huge-heavy shovelfuls, some mulch spilled on the ground.
I realized these tradeoffs, but thought “No big deal. Look how big my shovelfuls are!”
It wasn’t long before my father noticed that his Quality Rule #2 (“get mulch to him quickly”) had been violated, so like a good manager, he decided to check on the worker.
He was quite surprised to see me very slowly moving a heaping 16" tell shovelful of mulch into the wheelbarrow, spilling about 25% on the ground of it in the process.
Surprised, and upset.
I’ll leave the rest of the story to your imagination, but needless to say, my Quality Rule got tossed.
Why we get confused about quality
Let me present the concept of a packed phrase.
Words such as quality, performance, complexity, and scalability are packed phrases. Packed phrases are packed with so much potential information that we miss what’s important, rendering them useless without unpacking them.
Like lullaby langage, packed phrases give us the impression we’re clearly communicating even when we aren’t.
When you hear someone use a packed phrase, here’s a single, tiny question you can ask to start the unpacking process:
“Compared to what?”
For example…
- “The system needs to be fast.” “Compared to what?”
- “The legacy code is filled with bugs.” “Compared to what?”
- “The app needs to scale.” “Compared to what?”
- “Our process sucks.” “Compared to what?”
Asking this question usually receives one of two responses.* Information about the attribute the speaker feels is important.* A blank stare.
Both responses are useful.
More information is always useful.
But sometimes new information also contains packed phrases. Don’t worry, just repeat the question, “Compared to what?”
After doing this 2–3 times, people will catch on and strive to give more concrete ideas. Then you can continue your discussion.
What if you get the blank stare?
Just for you, I’m going to break the rules and reveal one of the Secrets of The Highest Order of Software Consultants.
Don’t report me to the grand poobah, okay?
If you get the blank stare… stare back at them.
Stare until it gets awkward (which it will!)
Don’t glare, just look.
If no one has spoken after you’ve silently counted to 1000, ask: “What happening for you now?”
This should jiggle them a bit, and allow you to resume the discussion.
Your goal is to help them become more specific in how they think (and talk) about these abstract concepts.
They are probably right that something isn’t good, but you can’t fix it without a clear definition.
Once you stop being content with ambiguities, they can too. This is a huge win-win for everyone.