The myth of the clean code base

Joining a new business or company as a software developer means getting familiar with their code base. Some companies might have a tidy code base. Others might run on a mess of spaghetti code.

But you’d be hard-pressed to find a truly clean code base. That is, an easy to understand, perfectly organised and structured code base. One with no duplications, technical debt or spaghetti code.

Here’s why the clean code base is a myth.

Clean code

Clean code is the goal for great programmers. It’s code that humans can understand — as well as computers. Writing code that a computer can understand is simple in comparison to writing code a human can understand. That’s the idea of clean code.

More than that, clean code is objectively good code. It’s efficient, with no duplications, written as succinctly and elegantly as possible. It’s structured in a way that’s easy to read for humans as much as it is for computers.

Clean code benefits dev teamwork because it’s easy to understand what the code does. It also makes for easy maintenance and easier debugging.

In a perfect world, striving for and writing clean code would result in a clean code base. That is, all your source code would be clean and easy to understand.

Unfortunately, even clean code has a shelf life. While your code base might start clean, problems of scale, time, expectation and author can cause it to dirty.

A problem of scale

When your code base is for a small program or project, it’s comprised of a few files of code. That’s easy to manage and maintain. You can take the time to update all those files and keep them clean and easy to understand.

When you start scaling up, though, it becomes harder. The few files that make up your code base turn into hundreds of files. Then thousands. Suddenly, your clean code base becomes harder to manage.

You’re adding features and functions, and as time goes on, you have dependency trees and database reliance. As your program grows, the risks of changing things can grow with it. It becomes easier to write a new function with an extra parameter than it is to change existing ones.

In short, the bigger the project or program, the harder it becomes to maintain that clean code base.

A problem of author

Another element that works against the clean code base is the number of developers. In most companies, given enough time, many different developers contribute code to the codebase.

When you enter a business and look at their code base, you aren’t seeing a product created by one person or one small, consistent team of people. Rather, you’re seeing many small changes that have happened over time, authored by a sequence of people.

Over time, then, code becomes harder to read by virtue of having different developers. After all, developers have different styles, different naming practices, and different daily focuses. And so, the clean code base remains a little more out of reach.

A problem of expectations

Another threat to the mythical clean code base is expectations.

A company’s development team will likely face deadlines. The dreaded ‘how long will it take’ question will rear its head from time to time. And, when an answer is given, it can result in a mad rush to get things finished.

This translates to shortcuts taken, technical debt accrued, and ‘dirty’ code added to the code base.

Then, a lack of forward planning may also hinder the creation of a clean code base. Features are started and left unfinished, for instance.

A problem of time

Finally, there’s the issue of time when chasing the clean code base.

Innovation and change are core components of the tech industry. Software and computing exist in a rapidly changing landscape. Code that was formerly clean code grows rotten; forgotten and outdated.

In other words, even code once considered clean code can become legacy code. Legacy code is code that works, but no one understands why. It’s no longer supported, written in an old language or under an old framework.

The older the code in your code base gets, the harder it becomes to understand. (No matter how well it was written in the first place.)

The myth of the clean code base

Even with the clean code base being a myth, all is not lost.

You should still strive for clean code — messy code only gets messier. Aim for readability, for consistency, for simplicity.

Just don’t expect to walk into a new company and immediately understand all the code that’s there. A code base might not be completely ‘clean’, but that doesn’t mean that it isn’t made up of good code.

Useful links

The positives of negative code

How do you deal with another developer’s bad code?

Legacy code dangers: code is inventory