Code rot is a form of Technical debt, which builds up over time. It is the process where the quality of the code deteriorates. It is largely unintentional (developers are not aware they're contributing to the code rot). However, it can be a conscience choice (lack of experience, knowledge or changing circumstances).

Code rot impacts productivity and morale, it is important to identify it and resolve it as soon as possible.

Basically its caused by failing to maintain quality in our code and architecture.

• Cutting corners because of lack of experience of pressures from management, users or clients.
• Not keeping documentation up to date
• Not monitoring external dependencies for updates / changes.

Unused code

Sometimes code becomes unreachable and isn't required anymore but doesn't get removed (We might need it in future... maybe?), the years roll on, and literally no one understands what this code does and why its there.

If it's not needed remove it.

$someBoolean = false;
// $someBoolean = $this->checkBooleanValue();

if ($someBoolean === true) {
    // Unused code here
}

Unreadable code

When code is edited without any regard for quality it becomes unreadable. You should be following a coding standard, adding comments and docblocks ALWAYS. Code should be subject to peer review (assuming those peers aren't also cutting corners too!).

After hundreds of edits it becomes a complete mess, people start avoiding it and waste hours trying to figure out whats going on.

if (
    $this->getSetting() === '1' ||
    $this->getSetting() === '2' ||
    ($this->getSetting() !== '1' && $this->someOtherSetting() === '1') ||
    (
    $this->getSetting() !== '2' && (
    $this->someOtherSetting() === '1' || $this->someOtherSetting() === '5'))) {
     // You get the picture!!
    }

Inconsistent data

Over time, your database may start to accumulate inconsistent data, e.g you might have 7 flags which all do similar or the same thing.

As platform requirements change there wasn't anything to refer to which might have made you realise not to add another database field and use what's already there.

You could have database fields such as:

• order_reference
• order_ref
• ref_order

You'd struggle to figure out which one to use? Or maybe you need to update them all because they're all used in different places throughout the codebase. If you try and fix it (by removing some) you'll introduce bugs so they never get touched and the confusion continues for you and the next developer who comes along!

Open for modification

For me, this is the biggest contributing factor. If you leave code open for modification, it's going to cause you issues further down the line. It's also something which can go under the radar especially if you're making the change only takes a few minutes, i.e can you quickly adjust this? Or can you tweak this code?

Seems fine, right? But as time progresses it becomes messy! If you try and push back and tell someone you might get ignored, because what you're suggesting might take a little more time and people can't see the issue with adding a few more lines of code.

But what do I mean? Surely all code should be open for modification?

Well... no, you should extend your code where possible. If coded correctly, the different behaviour to the standard version of the code would be attached or removed depending on given requirements.

Check out SOLID principles and in particular - OCP - Solid Principles Explained

Outdated documentation

Documentation can be anything which helps with development. It needs to be maintained, if documentation becomes out of sync with the code, it's hard for the developer to determine the correct behaviour. Requirements can be missed (which means unhappy clients!) and developers will take longer to figure out whats going on and no one knows if it's working correctly or not.

Avoiding code rot means a company can focus on developing new features. Efforts to prevent code rot should be ingrained into each developer, otherwise you're looking at damaging your code, your clients trust in you and your bottom line (£££!). Here are some of the main consequences you should actively try and active:

Bugs, bugs, bugs!

Code rot can hide existing bugs from developers and make it easy to introduce bugs when coding a new feature. If the code is unclear or data inconsistent, more bugs are going to crop up than if you were working on a clean codebase.

Slow development

Projects can be hard to navigate for developers if there's plenty of code rot to deal with. Simple changes (such as changing a dropdown) might end up taking days because of the state of the code.

Start measuring how long projects generally take and look at the task given, if it's a simple task then something is definitely wrong.

Low morale

Who likes spending time working on bad code? Developers do not want to be working on bugs / fixes all the time. Personally, I want to be proud of what I'm doing and be delivering a quality product which satisfies the given requirements.

Low morale means developer will decrease productivity and ultimiately end up leaving.

Assuming everyone now knows what code rot is, here are some solutions:

Train

Ensure developers are being trained and given the support they need. This means an ongoing training programme and being under the guidance of a competent technical lead, who is one hand to offer advice, solutions and point them in the right direction.

Identify

Identify areas which have code rot should be flagged for a rewrite (but properly this time!). Extend the code rather than leaving it open for modification (otherwise it'll need another rewrite before you know it).

Test

Create a testing suite and unit test areas of your code, to ensure they work as they should! Developers should feel confident making changes knowing that their change can be tested.

Document

This includes comments, docblocks and general documentation which helps developers understand what the code is doing! If a bug does arise, it can then be fixed in the right way, or if a new feature is required, you know what you can reuse within the system.

Stay calm

It's going to take time but as long as you've got the right leadership and they've started tackling the issue then you're good. There's no point re-platforming (thinking that is the solution) if you're going to keep making the same mistakes and not address the root causes (in a few years time you're back in the same situation).