Complex or complicated: why the difference matters (Part 1)
Every once in a while I am asked "Robert, despite all of our testing and monitoring, why is this software not performing as expected anymore? And I usually begin my answer with "It's complicated." Is it?
In other instances I listen to suggestions to build independent software modules that solely communicate through one, well defined interface so that absolutely nothing can go wrong because "It's simple." Is it?
The probably best answer to both questions is "Let’s look at the context and the system first.” Software development usually deals with a social environment. Even if you're a back-end development team: your back-end is used by a front-end. A front-end is used by people. And let's not forget, the development team and the company belong to a social environment that are shaped both by company culture and all the people that use and talk about the software. If you involve people, things tend to not be simple by default.
I became aware of complexity through a slideshare-presentation provocatively called Management Brainfucks, by Johann-Peter Hartmann, Chief Tailwind Officer at Mayflower GmbH. This excellent talk introduces the domains in which system can operate and transition to: simple, complicated, complex or chaotic.
You can put yourself into one of those domains by using a categorization model that was developed by Ralph D. Stacey back in the 1990s:
The idea is to take all the data you have (about your requirements, demands, team structure, client ideas, technology) and decide where in the model you want to put yourself in. When you start a new product you’ll most likely be in the anarchy space since everything is new. The more agreements you make and the clearer the approach is the more you move down to the bottom left. When you’re developing algorithms things are complicated, but manageable. When you’re designing and testing a UI it suddenly gets complex again. If things aren’t going well you’re close to anarchy again.
Why is it important to know where you are? Because if you know, you have a better way of understanding what to do next and how. I’ve seen another interesting conversion of the Stacey Matrix, presented by Jens Korte of mind to matter GmbH, used for risk analysis in business development. Whenever a business model canvas is created, there are assumptions made on the general approach and also the value propositions. This risk analysis model was developed to help discover which assumption to test first.
In this model you decide horizontally how much of your salary you would bet on an assumption to be true. Then you take this assumption and place it vertically based on the impact it would have if it proves to be wrong. Do that with all assumptions and you get the order of assumption testing you should undergo to avoid strategic problems.
If you compare this risk analysis model to the Stacey Matrix you’ll notice similar areas in a similar layout, just rotated by 90 degrees - with a single and important goal: to help you find out what to do first and which practice to use.
If you take the models and put your data in there they will help you to categorize and make smart decisions in the right order. Try to apply the models for your product and reflect on the possible actions that you can take. The exercise is great preparation for part two of this article, which will focus on a third model that will focus more on the emergence of behavior based on data rather than categorization based on a model - stay tuned!
References