3 Nasty ways complexity influences software projects

I have written about complexity in software development projects multiple times in the past. Wouldn't it be great to have proof for our engineer's gut feeling whenever we feel complexity in a code base or system? Wouldn't it be great to say that complexity is not only this itchy feeling, the appearance of goose bumps on our skin that tells us that this is way too complex for what it does? Wouldn't it be great to have proof for all the nasty things that will happen once complexity reaches a threshold?

If those questions resonate with you, keep reading.

3 complexity-driven nasty consequences

Many reasons exist for a system to be complex. The consequences arising from a complex system are often similar. They will fall into one of three categories:

• defects,
• productivity,
• staff turnover.

In his PhD thesis Sturtevant had a closer look at those three dimensions in a big commercial code base. He calls it a "Large Scale Commercial Software Firm" that produced "tens of millions of lines of code in many different languages".

What he found might not be surprising for engineers who looked at a few projects and companies in the course of their careers already. Why? Because most of the findings confirm the engineer's gut feeling. Still, having numbers put on the table come in handy when talking to other engineers and managers.

Complexity and defects

First, let's look at the expected number of bugs in a typical source code file. Here, code complexity (McCabe cyclomatic complexity metric) and architectural complexity matter a lot.

Files with high code complexity are expected to have over 2 times as many bug fixes as files with low complexity. The same you can observe with architectural complexity. In combination, the worst case scenario (high code and architectural complexity) could mean 8 times as many defects.

Now, let's look at the expected number of lines changed to fix bugs in a typical source code file. You can see a similar picture as above. There can be 3 times as many line changes necessary in a file of high architectural complexity compared to one of low architectural complexity.

When you compare a file of high code complexity with one of low code complexity you might end up with 2.6 times as many line changes. In the worst case scenario (high code and architectural complexity) you will need over 8 times as many line changes!

Complexity and productivity

There is a strong effect of architectural complexity on developer productivity. Going from low architectural complexity code to high complexity code results in almost halving the typical developer productivity (i.e., lines of code produced).

The effect intensifies when looking at the results relation of complexity and defects above. High complexity code usually means more work on bug fixes than features which is a reduction of productivity.

To summarize: reducing complexity would increase productivity because the developer would not need to work on high complexity code and bug fixes as much.

Complexity and staff turnover

This is an interesting one for managers and leaders. Architectural complexity is the strongest factor why an individual would leave a company.

While a developer working only on low complexity code has a 2% chance of leaving the company, working on high complexity code results in a 31% chance to leave! Forget fruit baskets, kicker tables and free beverages. Instead, make sure that complexity of your systems is low.

Conclusion

Overall, the thesis confirms the intuitive believes held in the software engineering community that complexity is usually bad and should be managed.

Refactorings that actually reduce architectural complexity have the potential to create huge financial value to companies!

Keep in mind, that this thesis focuses on the cost of complexity. First, there might be good reasons to build a complex system (e.g., for performance or security reasons) which offset the cost. Second, a refactoring might be more costly compared to what could be gained, hence, not doing it would make sense.

This is quite a bit to digest. I hope that this summary can be of value to anyone who starts a conversation about complexity of the system you are working on. Some outcomes will come in handy when you need to argue with fellow engineers or managers. I encourage you to have a look at the thesis for more details.

1. D. J. Sturtevant, "System design and the cost of architectural complexity", PhD diss., Massachusetts Institute of Technology, 2013