Understanding Essential and Accidental Complexity
Not all complexity comes from the problem. Some of it is introduced by the solution we choose. Understanding the difference between essential and accidental complexity helps us make better architectural decisions.
Since we explored domain boundaries and their types, this is the right moment to move forward and delve into the solution space. Before we proceed into the bounded context, it is worth becoming aware of one additional characteristic of that step.
Until now, we have been talking about the domain, its boundaries, and their importance. We were exploring the problem space. We learnt more about it - from language to complexity perspectives. All that knowledge is essential for us to be able to solve the problem. We have to understand its nuances and corner cases to be able to propose the right solution.
When we move to the solution space, it is important to remember a few things:
- There can always be multiple solutions to the same problem. Each comes with its own costs and benefits that we have to validate and compare to decide which one is the best for us at this point in time.
- Two people or groups of people can choose different solutions for a given problem, and for both of them, their choice can be the best possible one. Why? Because every decision is contextual. Part of that context is not only the problem itself, but also our knowledge, experience, and surrounding environment. All of these should be taken into consideration when the decision is made.
- Every decision comes with an opportunity cost and an implementation cost. The opportunity cost is the loss of benefits from the other options we did not choose. The implementation cost is the impact of our choice on everything we have to build, operate, and maintain.
Essential complexity
So what is essential complexity? This is the complexity that sits in the problem space. It is the part that:
- is relevant regardless the solution we chose,
- still exists once the solution has been chosen,
- contains all the details we need to deal with to solve the problem.
We cannot remove essential complexity simply by choosing a different implementation. It is inherent to the problem itself.
Accidental complexity
Accidental complexity is complexity that is not inherent to the problem itself, but comes from the way we choose to solve it and the environment in which the solution is implemented.
Every solution can introduce a different set of complexities. Additionally, the amount of accidental complexity can differ even for the same solution when different people have to implement it. This is where the context becomes particularly important. A solution that is straightforward for one team may be significantly more complex for another, simply because they have different knowledge and experience.
Let's look at the example
Let's pick one of the problems from the Training Center to see the difference between these two types of complexity.
The problem: validating the skills of a potential trainer.
Essential complexity in this situation is represented by the questions we need to answer to validate the trainer. Are we planning to simply ask them if they are familiar with the topic, or do we plan to have some difficult examination? Maybe it will depend on the history of our collaboration with them? Are we interested in evidence of their experience?
These questions exist regardless of the solution we eventually choose. We have to answer them if we want to solve the problem.
Accidental complexity, on the other hand, comes from how we decide to solve it. In our case, we may consider the following solutions:
- We delegate the process to an external company. Some accidental complexity comes from the knowledge required to find a good company, maintain the contract, and create a process for future collaboration and coordination.
- We can do it personally. The assessment itself is part of the essential complexity. However, choosing a manual process introduces additional complexity around conducting, coordinating, and documenting the interviews.
- We can build an automated system. Some accidental complexity comes from the knowledge required to build and maintain the system.
The complexity introduced by each option is therefore different. But it can also differ depending on the experience and knowledge of the people who implement the solution.
For example, if someone has been conducting such interviews for the last decade, the accidental complexity of doing it personally does not disappear. However, we already have the "know-how" required to deal with it. This makes the solution less costly to implement for that person than it would be for someone without that experience.
The complexity itself did not change. What changed was our ability to deal with it.
Summary
The distinction between essential and accidental complexity helps us understand what belongs to the problem and what is introduced by our solution.
Essential complexity is something we cannot get rid of simply by choosing a different implementation. It is inherent to the problem we are trying to solve.
Accidental complexity is different. It comes from the way we decide to solve the problem, and its amount depends not only on the solution itself, but also on the context in which that solution has to be implemented.
This distinction becomes particularly important when we move from the problem space into the solution space. It reminds us that choosing a solution is not only about deciding what we want to build. It is also about understanding the complexity that this decision introduces.
Comments ()