System's complexity graph

This diagram is a visualization of how design choices, refactoring and innovation impact the technical complexity of a software product. The theoretical line of minimal complexity at D is the general aim. Due to design choices in the face of incomplete information, advanced insight and other reasons, software usually ends up somewhere around the line of B, where the actual complexity is a bit higher. In this case, I explicitly limit the term complexity to mean the structural and/or architectural complexity of the project, so the software and hardware that makes part of it, it does not include the environment in which a project is installed or used.

The difference between the actual and minimal complexity at any time in the project is the complication, or technical debt. We get rid of this complication through refactoring, which at some point in the project can bring us onto the line of C. We should continuously evaluate the need for refactoring and consciously plan for it in software development, because too much complication is very wasteful for resources. As the line shows, to add other bits and pieces to the same software becomes an exponentially more difficult effort, involving more people, more meetings and it could lead to decisions not to build interesting features in the first place, so a loss of business opportunity.

Beyond refactoring, innovation can bring the line of minimal complexity itself down. Better approaches, runtimes, languages or libraries that solve core problems in software bring the entire graph downwards when implemented.

This graph also provides some intuition on how in small projects design choices have very low impact, but which, as the project grows, start to balloon in importance.

Read as a time graph, it also provides some intuition on the nature of how ambitious projects can become extremely complicated to manage. If this were a graph for a team of four people, then they manage to keep the complexity low. If this graph describes a product built by several different departments together, it becomes enormously difficult to keep complexity in check, because refactoring decisions impact other departments and breaks code all over the place, leading to interdepartmental standoffs.

Interesting to see what this graph would look like for an agile team. They tend to focus on features, removing complexity along the way, so they'd probably have a graph where B continues to jump back to C, back up to B again and back to C throughout the entire course of the project.