What’s that smell so bad? Maybe it’s your code.
The Tortoise and the Hare
What if I told you that The Tortoise and the Hare fable is really a story about Clean Code?
Yes, the right story is about Smells code, release, technical debt , don’t believe me? check it out then:
The classic The Tortoise and the Hare fable
The real History behind it
The fable ends here but the real history continues for a long time …
What is Code Smell
Code smells are not bugs, nor are they performance issues. In fact, your end user may never directly notice them. However, code smells indicate deeper problems in the code that make it harder to understand, extend, and maintain. Because of this, smelly code is also more likely to introduce bugs over time.
So while the user might not see the code smell itself, they can certainly feel its consequences—through glitches, slower updates, or unexpected behavior.
Why Should I Worry About Code Smells?
Code smells make your code harder to understand, maintain, and extend. They also increase the chances of unexpected bugs. All of this reduces the productivity of the development team.
Developers often spend a lot of time just trying to understand messy code—sometimes even code unrelated to the changes they want to make. Since the code is not clean, implementing any change becomes more difficult. Worse still, each change might introduce new code smells, making the situation even worse over time.
This is where technical debt comes into play—a term coined by Ward Cunningham. It’s a metaphor comparing bad code to financial debt. The “interest” is the extra effort required every time you make changes to messy code. Refactoring, or cleaning up the code, is like paying off that debt.
You might think, “But cleaning up code takes too much time!”—a common belief among developers. However, the truth is that keeping code clean is cheaper in the long run. At first, it might seem faster to skip the cleanup. But eventually, the code becomes so smelly that even small changes become difficult and risky. That’s when clean code actually becomes the faster and safer path.
I’ll include a couple of graphs from [1] to illustrate this.
Here you can see how the extra work required to add new features affects overall productivity. In [1], this is referred to as code cruft—another name for smelly code.
This pseudo-graph illustrates how, as code becomes more complex, productivity drops sharply when working with code that has smells or low internal quality. In contrast, productivity remains much higher when the code maintains a high level of internal quality.
So, the short answer to “Why should I worry about code smells?” is simple:
Because if you don’t, your productivity will eventually drop to zero.
What Does a Code Smell Look Like?
There are many types of code smells, each one breaking common best practices for writing clean, maintainable code. Let’s go over a few examples to better understand what code smells actually look like:
- Code Duplication:
When the same logic appears in multiple places, every change becomes riskier and more time-consuming, since it must be applied consistently across all instances. Miss just one, and you may introduce subtle, hard-to-find bugs. - Very Long Classes or Methods with Multiple Responsibilities:
When a class or method tries to do too much, it becomes hard to understand and maintain. Developers often end up dealing with unrelated logic just to make a small change, increasing the risk of accidentally breaking other parts of the system. - Unstructured Code with Poor Naming:
Code that lacks clear organization or uses vague names for variables, classes, or methods is difficult to read and even harder to modify. Every change requires extra time to interpret the code’s purpose. - Classes That Expose Implementation Details:
When a class exposes too much of its internal workings, even small changes can have unintended ripple effects throughout the codebase. This tightly coupled design makes the system fragile and harder to evolve safely.
When and Why Does Code Start to Smell?
In his book Clean Architecture, Robert C. Martin (Uncle Bob) points out that one of the biggest reasons code starts to smell is developer overconfidence. Yes—confidence.
He explains that when the pressure is on—tight deadlines, production bugs, last-minute feature requests—developers often throw clean code practices out the window. They believe they’ll come back later to clean up the mess once the deadline is met. But in reality, that moment rarely comes. The pressure doesn’t stop. New deadlines keep piling up. As a result, the quick-and-dirty code becomes permanent.
Uncle Bob compares this behavior to the hare in the fable The Tortoise and the Hare. The hare is confident it can catch up at any time, so it rushes ahead and then gets lazy. Developers today act the same way—confident they can “switch back” to writing clean code at any moment. But by the time they try, the codebase is already a tangled mess.
What the Research Says
In a study of over 500,000 commits across 200 open-source projects, Michele Tufano and his colleagues (summarized well in [4]) found some revealing insights about when and why code smells are introduced:
1. Most Code Smells Are Introduced Early
Surprisingly, many code smells appear at the very beginning of a project.
From my own experience, I’ve only worked on one project from scratch after leaving university. Even in that case, we were always in a rush to get the first version out. That rush leads to messy, unrefined code—and unfortunately, those early decisions often stick around for a long time.
2. Experienced Developers Introduce More Smells Than Newcomers
This might sound counterintuitive, but it makes sense when you consider overconfidence again. Experienced developers may feel comfortable making large changes or taking shortcuts because they understand the system well. They believe they can clean it up later—but that moment often never comes.
It’s a reminder that clean code should be treated as a necessity, not a luxury [4], no matter how experienced the developer.
3. Most Smells Are Introduced Just Before a Release
Tufano’s team found that 89% to 98% of code smells were introduced in the month leading up to a major release. When deadlines are near, corners get cut. But this short-term thinking leads to long-term pain. Rushed code becomes legacy code almost instantly.
4. Busy Developers Introduce More Smells
According to the study, 55% of the developers who introduced new code smells had a high workload. When developers are juggling too many tasks, code quality often suffers.
Many developers think cleaning up code is too time-consuming. But in reality, messy code costs more in the long run. No matter how busy you are, keeping your code clean will always pay off.
What’s Next?
Now you might be thinking:
“Okay, I get that code smells are bad—but how do I avoid them? And how can I even recognize them?”
Here are a few recommendations to get started:
- Build a Clean Code Culture
Help your team understand that clean code isn’t a luxury—it’s a necessity. In the long run, clean code is cheaper and more sustainable than smelly code. - Encourage Code Reviews
Code reviews become much more effective when everyone is committed to keeping the codebase clean. It’s a great way to spot smells early and learn from each other. - Use Tools to Detect Code Smells
There are plenty of tools and platforms that can automatically analyze your code and highlight potential smells. These can be valuable in maintaining high-quality code over time.
Of course, this is a much bigger topic—and one that deserves its own post.
So stay tuned—more on this coming soon!
Reference
[1] https://www.martinfowler.com/articles/is-quality-worth-cost.html#SoftwareQualityMeansManyThings
[2] https://www.martinfowler.com/bliki/TechnicalDebt.html
[3] https://medium.com/the-liberators/on-technical-debt-and-code-smells-ae8de66f0f8b
[4] https://www.linkedin.com/pulse/clean-code-isnt-programming-luxury-its-business-necessity-gorman
Discover more from Learning Together
Subscribe to get the latest posts sent to your email.
