“Complexity” is characterized by lots of different interconnected parts, physical or otherwise. The human body is complex; a single-celled organism is not (well, not as complex, anyway). The problem with complexity is that in any system, each component is potentially affected by each other component. That means adding any single component to a system exponentially increases the complexity.
For example, with 3 components, there are 7 different combinations of components that could interact and create an issue (3 combinations of 1, 3 combinations of 2, 1 combination of 3). With 4 components, there are 15 different combinations (4 combinations of 1, 6 combinations of 2, 4 combinations of 3, 1 combination of 4). With 10 components, there are 1023 combinations (I’m going to simplify it here and tell you that the equation is 2^n-1. You subtract 1 because there is 1 combination of 0, which generally shouldn’t affect anything).
The lesson here is to simplify if at all possible, to minimize potential errors and make maintenance easier. I generally subscribe to Einstein’s viewpoint (and a fundamental principle of design!), “Everything should be made as simple as possible, but not simpler.” There will obviously be times when a system cannot be reduced to fewer components, so the question is, how do we deal with those systems?
If you’re reading this blog, you probably know that ArgonDigital’s solution to this problem is to use visual models to increase understanding and reduce ambiguity. The reason those models work is because they represent various levels of abstraction. What that means is, all of those components can be grouped in such a way make it possible for one person to quickly comprehend the problem.
For example, let’s say that your car won’t start, and you don’t know why. The highest level of abstraction is obvious: your car. The next level of abstraction would be the largest groups of components: engine, motor, wheels. If you can isolate that the problem is in the engine, then you don’t need to understand every individual piece of the car – just the ones in the engine.
You can see how this thinking applies to systems from large corporations (corporations are divided into business lines, which are divided into geographies) or even the human body (bodies are divided into organs, which are divided into tissues, which are divided into cells). To visually model software requirements, I prefer to use feature trees, which group each requirement into the feature that the user values. Instead of dealing with 1000 requirements, I can deal with 50 features. How do you deal with complexity, either in requirements or any other context?
