Author: Ben Turner Published on: 13th of November, 2020
Sometimes in our goal to reduce duplication and organise our code, we introduce abstractions and tools that increase the complexity of our codebase dramatically, making it less readable, less robust and less maintainable, and we do so without realising it.
One common instance where this can occur is when we abstract prematurely, adding in code constructs to handle redundancies that don't yet exist, and may never exist. But another common cause of this accidental increase in complexity, is introducing complexity by using tooling or code constructs that are not solving the core domain complexities, and that also introduce their own set of problems. These newly introduced, extra-curricular problems are often referred to as Incidental Complexity.
Domain complexities are problems inherent in our domain space, problems we must solve with our software. Like the need to handle multiple payment processors, or the need to apply tax to an order based on it's sale location. Those are smart times to make abstractions and introduce tools, because the problem is inherent in our domain. It's worth having smart, organised tool sets to handle those problems that you can use throughout the codebase.
Incidental complexity on the other hand, doesn't add value to our codebase, and doesn't solve our core domain problems. They're complexities created and introduced by the programmer or the tooling choices. For example, a simple blog website that has chosen to use the Entity Attribute Value data structure to hold it's data. When you need a data structure as complex to implement as EAV, it's a very useful tool. But when you do not need it, you're introducing a huge development overhead into your project without getting any value in return.
So it is perhaps more accurately looked at as accidental complexity. Complexity introduced by not properly understanding the scope of the problem you're trying to solve with your software, and then choosing the wrong tools and paradigms to use in your codebase. If we look at it this way, we can realise that reducing incidental complexity is part of good software development, and we should strive to reduce complexity wherever possible.