What If We Made Bugs Illegal?
Let’s say someone in power and zero clue* woke up and said: No more bugs. If your app has a bug, you’re fined. Or jailed. Or worse, made…
What If We Made Bugs Illegal?
Let’s say someone in power and zero clue* woke up and said: No more bugs. If your app has a bug, you’re fined. Or jailed. Or worse, made to maintain a legacy AngularJS codebase. Imagine that world.
What would you do in that situation?
My first instinct:
MOOORE TESTS!!!
Unit tests, integration tests, end-to-end tests, snapshot tests, mutation tests, contract tests, visual regression tests, load tests, chaos tests. Test the tests.
I would ship like defusing a bomb, slowly, carefully, double and triple checking every line of code. On top of that, I’d hire an army of manual testers to click through every flow, and have a code freeze until their sign-off.
In this dystopian world, full of bureaucracy and fear, I can imagine everyone being miserable and exhausted. Sooner or later, despite all the processes, a bug will find its way to production because complex enterprise software doesn’t care about our safeguards.
But the truth is that bugs aren’t illegal. No one’s going to jail. There’s no QA death squad waiting for your next deploy.
And that’s exactly the problem.
We’ve normalized the things that let bugs through.
We work with incomplete requirements and do our best to fill in the gaps.
We accept constant scope changes and hope our tests still cover the right cases.
We rely on flaky end-to-end tests and call it good enough when they pass on the second try.
We ship without monitoring, without alerts, without knowing if anything even broke.
Too often, we treat bugs like an inconvenience instead of a responsibility.
We move fast, cut corners, write just enough tests or not at all, and assume someone else will catch the fallout.
But what if we did write code like bugs were illegal?
What if we actually owned the outcome?
This doesn’t mean paralyzing fear or endless processes.
It means writing code you believe in.
It means testing like someone else’s job depends on it.
It means catching bugs before they hit production, not running to fix them after.
No one’s making bugs illegal. But maybe they don’t have to.
Maybe we should just start acting like they already are.
The Action Plan
If you’re on board, here’s the action plan. Nothing fancy. Just what responsible developers usually do.
- Test by default. If it’s not tested, it’s not done.
- Cover the edge cases. Life is easy on happy paths. But things will go wrong. Write like you know that.
- Fix what’s flaky. A failing test you ignore is a bug you’ve accepted.
- Monitor what you ship. If you don’t know when it breaks, you’re not done.
- Fail loudly. Silent failures are the worst kind. Make bugs obvious when they happen.
- Don’t guess requirements. If it’s unclear, ask. If it keeps changing, pause.
- Keep it small. Small functions, small PRs, small changes. Less surface for bugs to sneak in.
- Don’t ship TODOs. If it matters enough to write down, it matters enough to finish.
- Delete dead code. If it’s not used, remove it. Clutter hides bugs.
- Review code like it’s yours. Because it is, once it hits master.
None of this is hard. Most of it is just a decision.
So make it.


