Tame Complexity

Sources of complexity

In industry, it won’t be long before we run into a mind-boggling mess of code: The Behemoth, The Spaghetti Factory, The Legacy System from Hell, all names of the same dreaded problem.

Complexity in software systems is unavoidable. Some problems are just hard, and their solutions are complex. However, much of the complexity we find in software is a mess of our own making. In the book “The Mythical Man-Month”, Fred Brooks separates the two sources of complexity into necessary and accidental complexity.

Here’s a way to consider the difference between necessary and accidental complexity: what complexity is inherent in the problem domain? Let’s say we’re faced with a program that has date/time-handling code scattered all over the place. There’s some necessary complexity when handling time. Months have different numbers of days, and we have to consider leap years and so forth. But most programs have loads of accidental complexity relating to time: times stored in different formats, novel (and buggy) methods to add and subtract times, inconsistent formats for printing times, and much more.

The complexity death spiral

It’s very common in programming that the accidental complexity in a product’s codebase gradually overwhelms the necessary complexity. At some point, things devolve into a self-amplifying phenomenon we can call the complexity death spiral.

Problem 1: Code size

As we build a product, its code size will grow vastly beyond any school or hobby project. Code bases in the industry are measured in thousands to millions of ...