Why Some Code Smells Stay Forever
Every engineer has done it.
You find a method that’s 400 lines long.
A class that does ten unrelated things.
A function called handleEverything() that actually does.
And you think:
“Who wrote this?”
Then you check git blame—and realize it was you.
Code smells aren’t always accidents
Sometimes you’re in a rush.
Sometimes you inherit chaos.
Sometimes the business changes before the system can catch up.
But more often, a smell is a signal.
Not of incompetence.
Of tradeoffs.
- That long method? It was written under pressure to meet a launch.
- That God Class? It started as a simple module and quietly grew without boundaries.
- That feature envy? It’s what happens when team ownership is fuzzy and APIs are slow to evolve.
These aren’t bugs in the system.
They’re consequences of the system.
Why engineers tolerate smells they hate
The paper “Study of Code Smells: A Review and Research Agenda” breaks this down clearly.
Smells stick around not because engineers don’t care—
but because they care about other things more.
Deadlines. Velocity. Team dynamics.
Uncertain ownership. Tooling gaps. Review fatigue.
Code quality isn’t just a technical decision.
It’s political.
It’s emotional.
It’s negotiated.
Some fixes cost more than the smell itself
Every engineer can spot a long method.
But how many can untangle it without introducing new bugs?
Every manager can ask for cleaner code.
But how many can create space in the roadmap to support it?
You don’t refactor because something is ugly.
You refactor because it’s safer, faster, or cheaper to clean now than to leave it alone.
And that’s a hard sell when your users don’t care what your class hierarchy looks like.
Living with smells is part of the job
The longer you write code,
the more you realize the real skill isn’t spotting bad patterns.
It’s knowing which ones matter.
- Which ones are hurting clarity today?
- Which ones are technical debt, not emotional debt?
- Which ones can you work around without compromising quality?
Fixing everything is a fantasy.
Managing mess is a discipline.
And sometimes the worst smell… is fear
You know what’s worse than a God Class?
A team that’s afraid to touch it.
A team that tiptoes around messy code.
That writes new logic in weird corners to avoid opening the monster file.
That’s how rot spreads.
That’s how teams start avoiding responsibility.
The real cost of smells is rarely technical.
It’s cultural.
The senior engineer’s job isn’t to clean everything
It’s to make smart bets.
To draw clear lines.
To refactor with purpose—not pride.
And sometimes, it’s to leave a mess behind with a clear TODO
and the context someone else needs to fix it later.
Because you’re not here to write perfect code.
You’re here to build software that works
and teams that don’t break trying to maintain it.