Understanding the type of bug can be more useful than knowing the root cause. Here’s why.
When someone has a stroke (as I’ve recently learned), the symptoms might look the same—slurred speech, weakness, confusion.
But underneath, strokes fall into two very different categories:
- Ischemic (a clot)
- Hemorrhagic (a bleed)
And the treatment? Almost the opposite.
One needs blood thinners.
The other needs the bleeding to stop.
Get the category wrong, and the cure becomes poison.
You don’t need to know the exact root cause—just the type. That’s often enough to apply life-saving treatment.
A similar principle applies to software bugs.
You don’t always need to know the exact root cause to make progress.
Often, just recognising what kind of problem you’re dealing with shows you the pattern — and points toward the right fix.
I group bugs into two main types:
Doing the thing wrong
Understanding the problem, but the solution was built badly.
It’s like putting a plaster on the wrong finger.
The original cut’s still bleeding, but at least they brought a first-aid kit.
The intent was good. The aim was just off.
Doing the wrong thing
Misunderstanding the problem and building the wrong solution.
Like cutting off an arm to fix a papercut.
You can see what they were trying to do.
But now a limb is missing — and the papercut’s still there.
These types of issue are worse: causes more damage, harder to undo
Both types matter.
They need completely different approaches to catch—and to prevent.
When people talk about bugs, they usually mean “doing the thing wrong.”
A broken button. A syntax error. That one sneaky line that forgot how logic works.
How do you catch them?
- Well-defined acceptance criteria, and verifying they’re met
- Automated tests
- Code coverage checks—especially for the code that was just changed
In all my years as a QA, I’d estimate that 95% of the bugs I’ve found were just syntax errors.
Simply hitting all the lines of code would’ve caught them.
Some developers scoff at code coverage, but what’s the alternative? Vibes?
Then there’s the “doing the wrong thing” type of bug. Which is a whole other beast—and it’s much less widely discussed.
These kind of bugs are brutal.
Because everything can look like it’s working—until it really, really isn’t.
I’ve had to be the one to tell a developer:
“Hey… this doesn’t actually solve the problem.”
It’s awkward. It sucks.
Sometimes it means throwing away days—or weeks—of work and starting again.
Not because the code was bad.
But because the problem wasn’t understood properly from the start.
It’s demoralising. It burns trust.
And yet… this kind of bug gets far less attention than broken buttons or red error messages.
These bugs are born before the first line of code.
It begins with a misunderstanding of the problem, or a vague definition of the solution.
And worst of all? You can’t catch them with tests or coverage. Because they “work.”
They’re just wrong.
The best time to catch these is before the work starts—during backlog refinement or ticket creation.
Red flags to watch for:
- One-sentence tickets are crimes. Don’t let them slide. Pull them up in planning. Mercilessly.
- No clear problem definition. If no one can say what the user is trying to do, don’t start.
- Vague solution. It should be clear how it solves the problem
- No edge cases. There are always edge cases. If there aren’t any, it means no one looked.
Defining the ticket is development.
It’s the hard bit. The thinking bit.
If you’ve done it right, implementation should be the easy part.
Like planning a road trip: once you’ve mapped the route, the driving is just… driving.
But if you start without a plan, what are you doing?
Everyone—developers, QA, product owners—should be able to look at a ticket and say:
“I understand the problem, and I can see how this solves it.”
As a QA, I hated that second type of bug.
It was so preventable.
But I’d only discover it after the feature was built.
I used to wish I could go back in time and stop it from happening in the first place.
Then I became a Scrum Master.
I started leading backlog grooming. I made sure vague, half-baked tickets didn’t make it through.
No loose ends. No “we’ll figure it out later.”
And just like that, we eliminated that entire category of bug.
Yes, we still had broken code—but that’s easier to fix.
The real disasters? Gone.
That’s why I believe QAs make the best Scrum Masters.
Because they’ve seen what happens when things go wrong.
When someone has a stroke, doctors don’t always know the exact root cause.
But they don’t need to.
They just need to know: is it a clot, or a bleed?
Because the treatment is urgent. The clock is ticking.
And that’s why simple, high-level categories matter.
They let us develop strategies—clear, effective ones—for identifying and treating each type.
Strategies that can be life-changing.
Software isn’t life or death (usually).
But like medicine, better diagnosis leads to better outcomes.
Davide la Locomotive 
Leave a comment