In 1986, the Turing Award winner Fred Brooks wrote a paper called No Silver Bullet – Essence and Accident in Software Engineering made a distinction between two types of complexity—essential and accidental complexity. Inherent complexity is coming from the domain, from the problem itself, and it cannot be removed without decreasing the scope of the problem. In contrast, accidental complexity is brought to the solution by the solution itself—this could be a framework, a database or some other infrastructure, different kinds of optimization and integration.
Books argued that accidental complexity level decreased substantially during those years when the software industry became more mature. High-level programming languages and efficient tooling give programmers more time to work on the business problems. However, as we can see today, more than thirty years later, the industry still struggles to fight accidental complexity. We will discuss some possible reasons for this phenomena in the next section.
You probably noticed that essential complexity has the strong relation to the problem space and accidental complexity leans towards the solution space. However, we often seem to get more complex problem statements than problems itself. Usually, this happens due to mixing problems with solutions, as we discussed before, or due to a lack of understanding.
Gojko Adzic, a software delivery consultant, author of several influential books like Specification By Example and Impact Mapping, is giving this example on his workshop:
The company then decided to analyze the actual need that the customer, who requested this feature, had. It turned out that the customer wanted to perform the same operations as they were doing before, but instead of doing it monthly, they wanted it weekly. When asked about the desired outcome of the whole feature, the customer then said that running the same report batched once a week would solve the problem. Re-scheduling the database job was by far easier operation that redesigning the whole system, while the impact for the end customer was the same.
This example clearly shows that not understanding the problem can lead to severe consequences. Developers tend to generalize and bring abstractions to solutions, and very often this is entirely unnecessary. What seems to be the essential complexity in this example, turned out to be a waste:
The picture above shows that with the ever-growing complexity of the system, the essential part is being pushed down and the accidental part takes over. When systems become more prominent, a lot of effort is required to make the system work as a whole and to manage large data models, which large systems tend to have.
DDD helps you focus on solving complex domain problems and concentrates on the essential complexity. To do this, DDD offers several useful techniques for managing complexity by splitting the system into smaller parts and making these parts focused on solving a set of related problems. These techniques are described later in this book.
The rule of thumb when dealing with complexity is—embrace essential, or as we might call it, domain complexity and eliminate or decrease the accidental complexity. Your goal as a developer is not to bring too much accidental complexity. Hence that very often the accidental complexity is caused by over-engineering.