How Code Rots (and What To Do About It)

Just like humans, animals, and opinions, websites age. They get older. They become less responsive. If left to their own devices, they struggle to keep up.

This means — again, just like humans, animals, and opinions — websites need to be cared for. They need to adjust to their environment and improve for the times. We (as people) go to the doctor, exercise, improve, and follow healthy choices. Websites need the same level of care.

So, what is “code rot?”

When we think of a rotting tree stump or the contents of a compost bin, we’re thinking of “rot” as a destructive force. Of bacteria attacking and breaking down organic matter  — something that happens to a piece of vegetation.

Code rot, on the other hand, has no physical attributes: in fact, the term “code rot” is a bit of a misnomer — it isn’t that systems and code are getting worse, but that they’re falling behind in a way that begins negatively affecting the quality of the system itself.

Here’s a real-world example: if you have any app-focused device older than a few years — a television, a smartphone, etc. — you’ll notice that the device itself begins running slower and slower over time. Menus don’t load as quickly, and some apps aren’t even available.

In most cases, this is not because the device is getting worse — the television itself isn’t falling apart, after all — but because the ecosystem that surrounds the device is getting better, and there’s no easy way to bring the device up to speed.

So too with code. Various standardization committees, browser providers, and new inventions in web development all improve upon what’s already been done. But older development projects don’t employ all of these new technologies — and, at times, can be using technologies that have since been proven to be harmful to performance or accessibility.

That’s code rot.

Tackling code rot head-on.

An aging digital experience platform (DXP) or content management system (CMS) isn’t the end of the world — but it’s also not something that should be ignored. Improvements and changes in technology tend to stack, meaning leaving a few small issues to rot will lead to much bigger problems down the line — more bugs, a more tangled codebase, and a lot of frustration within the development team and beyond.

Audit the current code.

First, you’ve got to know what you’re dealing with. Tackling code rot head-on means understanding the scope of the code itself. Auditing code for bugs, mistakes, and unused code will help identify areas of improvement.

When a developer audits a site for code rot, they’re looking for things like incorrect or outdated class names, a lack of standards, or even changes that have occurred in the software itself. A recent accessibility update may have left behind some older, unused content types. A database integration that’s no longer used may still have remnants of its existence living in the code.

Each issue has a cost, and more systemic issues can lead to technical debt, at which point the issues of old and unused code begin to cause more problems than can be fixed through day-to-day development work.

Clear out unused code.

Websites are unique in that they are built for now, but with the future in mind. Neither of those two states includes the past, but know that your website also has a lot of skeletons hiding in the nooks and crannies of the codebase.

First, as you’re auditing code, work with someone on the content or design team to better understand what pieces are still being used. Issues due to unused code are chalked up to “dormant rot.” Your code isn’t actively causing problems, but it’s still a risk — because of how interconnected code is, often old, unused code causes complications with code that still is in use, just by existing.

For example, if your organization no longer hosts events, then maybe you’ve suppressed the calendar within the site. Know, however, despite not using the content types, that code is still there. Websites are interconnected, so integrations, blocks, and even basic design elements may still rely on the code used within the calendar.

Review integrations.

This is all fine for the code you’ve created, but how do you handle complications that arise through code that you’re only partially responsible for?

Integrations — from social sharing icons to complicated APIs, from database synchronization to a digital asset manager — rely on their own code to do whatever it is they were built to do. In order to integrate two separate code bases, a lot of unique solutions are developed — often solutions that are used only for that integration. This leads to two potential issues.

First, external integrations may have undiscovered security vulnerabilities, which come to light after the integration is forgotten about but still hanging around. There’s an obvious risk in this situation.

Second, if an integration is discontinued or sunsetted, remnants of that integration may still remain. Whether an integration is removed (such as removing a social sharing button from a content type), abandoned (such as an editorial team ignoring an old feature in favor of something newer), or completely broken (such as when an integration creator shuts down or removes a feature from the ecosystem), code from these integrations doesn’t just disappear.

Stopping code rot before it starts.

Of course, there are methods to building a site that set it up better for the future — from steering clear of too many dependencies, to scheduling and following through with ongoing site review.

Coding with standards.

The push for web and development standards started early in the web’s life. Even before our current rate of millions of new websites per year, developers focused on making sure there was some consistency and boundaries.

But web standards aren’t just a set of rules. They’re an unspoken understanding between developers, browser creators, and users. Clever code is not always good code. “Good code” — often defined as “as simple as possible, but no simpler” — works logically on as many devices and browsers as possible. Good code leads to fewer surprises, which leads to fewer weird issues, fewer bugs, and fewer cases of the web moving too fast for your site.

Clever code does not age well. Boring, clean, simple code usually stands the test of time.

A strong testing process.

Of course, standards mean nothing if no one is there to catch the mistakes. A strong, consistent, and empowered testing process catches errors before they get too far.

This means testing both code (we’ll talk about code reviews in a second) and also functionality. There’s a tendency for minor inconveniences to be overlooked or pushed to the backlog — a case of, “it should work better, but I can make do for now.” Testing and prioritizing editorial complications (or, even worse, editorial hacks) helps keep code clean beyond just the “site breaking” errors.

Ongoing monitoring also helps ensure things are running smoothly. Whether you’re performing regression testing to ensure old features work both before and after major code changes, or whether you’re monitoring performance metrics like page speed and site accessibility, keeping a constant eye on the entire package helps identify rot long before it takes over.

Plan for technical debt.

Finally, the best way to prevent code rot is to create a place where code rot is always being prevented.

A culture of code review — in which all code is reviewed by another developer familiar with the project — doesn’t just find mistakes and clean up the rough edges. It also helps develop a process and expectation by which code is always scrutinized. It’s simply part of the process, leading to fewer mistakes that get lost in the code until they’ve been built upon.

Additionally, when new features are proposed or developed, having someone who knows the code — and can help navigate the complications of a new integration or content type — will help make sure new code can be easily integrated into the existing site.

Conclusion

Everything gets older. So too with websites — code rot is part of the natural development process, and every site will eventually lose functionality and get buggy as technology advances and drops older languages.

That isn’t to say it’s something worth ignoring. Tackling code rot takes a little bit of reflection and a lot of forward thinking — to know when to update, and to understand how to build in the first place. With a bit of attention and a focus on staying up on standards, every site can prolong the rot — at least for a little longer.