Yes, I know it’s moot. That’s the point.
“Mute” means silent. “Moot” means debatable.
When no one speaks up and no one agrees, you waste time.
In software, unclear language isn’t just awkward—it breaks processes.
Here’s what happened when we finally defined “bug” once and for all.
A common way we learn words is called contextual acquisition—inferring meaning from how others use them, without ever cracking open a dictionary.
Most of the time? It works.
But sometimes, it goes a bit wrong. We mishear the word or absorb the wrong definition. We end up walking around confidently misusing a word.
Like when someone says a group is “clicky.”
Maybe they’re describing a troupe of arthritic line dancers (whose performances are… audible).
Or maybe they meant “cliquey,” and just misheard it.
This is an eggcorn – mishearing something and replacing it with a word that still makes sense.
Eggcorns are especially sneaky: they sound right, but can twist the meaning:
- “Cliquey” comes from 18th-century France—a small, exclusive group.
- “Clicky” sounds similar, but suggests everyone gets along.
That subtle shift? It matters.
The same thing happens with words and ideas in software development.
Terms like “bug” get absorbed through context—we hear them used and assume we understand.
But we rarely stop to define them.
I was a Scrum Master for a development team. We had a huge backlog of bugs, and every week we’d slowly review them. Again and again, the same question came up:
“Is this really a bug?”
Part of the problem was that everything was getting written up as a bug.
Feature requests, enhancements, even vague suggestions—if it went in the backlog, it wore the bug label.
If everything is a bug, then nothing is.
When you give every ticket the same label, they all end up with the same priority.
Which means:
- Actual defects don’t get fixed.
- Broken things stay broken.
- The tool stops feeling trustworthy.
And when nothing improves — not because people don’t care, but because the system’s too foggy to steer — the team starts to drift.
No direction. No signal. Just backlog inertia.
That’s when developers start to lose heart.
“Bug” should mean a defect—something broken that needs fixing.
That’s different from something new we want to add.
Enhancements, features, tech debt—these all matter. But they need to have the correct labels.
We were stuck in circular conversations, so I offered to write a definition of “bug,” complete with examples. As a team, we reviewed, updated, and agreed on it.
And… it worked.
We stopped arguing. The bug count dropped dramatically. Everyone was on the same page.
So what is a Bug?
Imagine your software is a car:
- The engine won’t start?
- That’s broken functionality.
- You steer left and the car turns right?
- That’s incorrect functionality.
- Doesn’t have a windscreen?
- That’s missing functionality.
- You put your foot down and it maxes out at 15mph?
- That’s a performance bug.
- You can start the car with a spoon?
- That’s a security bug.
A bug is when something’s broken. Not “annoying.” Not “could be better.”
Broken.
What’s not a Bug?
Still using the car metaphor:
- You want neon pink lights under the car?
- That’s a new feature request.
- You’d like the radio to also stream podcasts as well as FM?
- That’s a feature enhancement.
- You want to move the gear stick to the other side because just because you prefer it?
- That’s a behaviour change.
- You’ve been meaning to replace the rusty brake lines for two years?
- That’s tech debt.
None of these are bugs.
They’re valid. They matter.
But they need their own labels.
We often assume we’re all using the same definitions—especially for words we use every day. But without a shared understanding, confusion creeps in. We “nipped it in the butt” by agreeing what “bug” meant.
This is not just limited to bug but to many other terms used in software development and Scrum.
The fix is the same: create a shared understanding.
Language is like code.
When everyone uses their own definitions…
you’re going to get bugs.
Davide la Locomotive 
Leave a comment