Mastering complexity

Relax, every code base rots over time

JAXenter Editorial Team
Rotten image via Shutterstock

How do you know if your code base is rotting? Before you get defensive about your code, software architect Erik Dietrich wants you to know that every code base rots over time. The key is to ensure you’re managing the complexity of its growth correctly.

It’s hard to write clean, well-structured and streamlined code that is easily expanded on and still performs well after five years. But don’t worry: If you don’t succeed in building this kind of code base, you’re not alone. Nearly every project decays over time – and it’s not necessarily due to lack of skill…

… rather, there’s mathematical reasons for this, says software architect Erik Dietrich.

The complexity of communication doesn’t grow linearly

Dietrich starts with a little thought experiment: Imagine we’re working alone on a project. The communication that is required to clarify individual work steps is equal to zero. But there comes a time when a project becomes too large for just one person and more people are needed.

The number of people working on it grows to three, so now there are three lines of communication: between A and B, B and C and A and C. A fourth person added to the mix now equals six lines of communication, because suddenly A speaks with B, C and D, B also chats with C and D, and finally C and D connect in order to ensure comprehensive communication lines.

The point here is that the complexity hasn’t grown linearly but exponentially. When an additional person is added to collaborate, a communication line to already existent collaborators is needed, meaning 20 people will call for a whopping 190 communication lines. Eventually, the team begins to work less and spend more time in communication mode.

But what does this have to do with code?

Complex code

Dietrich looks at the analogy between team communication and software architectures: The complexity of a code base doesn’t increase linearly, but exponentially with the number of logical units or modules that have an application. Pure Mathematics. The communication overhead between these units is growing exponentially as well as increasing team structures, and is nearly unmanageable without appropriate countermeasures.

The crucial question is, what are appropriate countermeasures? Again, the metaphor of teamwork further helps with his point: Every manager with common sense would split up teams consisting of 20, 30 or 40 people immediately. The more people there are on a team, the more problems it creates (rather than solutions).

SEE ALSO: Learn to code, its harder than you think

It’s therefore necessary to create smaller units that require less communication overhead to operate. The communication between these subunits would be reduced to what is strategically necessary.

With respect to a code base, that means minimising the size and complexity of your code components. It means eliminating the unnecessary dependencies in favour of adjoining logical units. Dietrich suggests that we attempt to eliminate risky communication bottlenecks, and if this isn’t possible, to at least establish a backup strategy.

Finally, it’s important to evaluate and continually monitor the entire structure of your code base to ensure that your architecture is improved, or at the very least, doesn’t degrade further.

What’s the lesson?

From the metaphor presented above, we can learn two things. First of all, it’s not uncommon for code bases to be forfeited due to their complexity and one’s inability to control it. Almost every programmer has come across it and it’s not trivial to try and prevent it from happening. No one should have their ego or pride as a developer hurt when an analysis tool or external party has discovered vulnerabilities in “their” code. Dietrich says relax!

Secondly, it should be the aim of every developer to learn to better manage complexity. While managers tend to dissolve large, opaque teams faster than one would like, they will react to large, opaque applications only when it’s too late.

The complexity of an application isn’t easy to recognise at first. Code reviews, analysis tools or clean code training can help to assess the impact of a new code component to your overall system and allow developers to better understand the complexity of an application.

Inline Feedbacks
View all comments