Complex solutions require complex configuration or strong convention

One of the observable phenomena in engineering is that as a system becomes more complex, using it or realising value from it requires the use of complex configuration, or strong convention to reduce complexity. Understanding the implications of this idea allows us to a) design complex systems with usability in mind, and b) be able to critique a large amount of software marketing in the world.

For the purposes of this post, I want to explore a few examples where we can observe this idea. To start us off, consider a car. A car is a fairly complex system that has been reduced (to the driver) down to a set of simple inputs. This means the car forces a strong convention. In other words, your ability to change how the car operates as a driver is fairly limited, instead, you are required to follow the way the designer has set it up for you.

In keeping with the theme of cars, we can expand this view to traffic as a whole, which also relies heavily on strong convention. On a freeway/motorway/highway/caraway, you are able to "configure" your driving by changing lanes or taking an exit (weak configuration), and in turn, you know everyone else will follow the same set of basic rules (strong convention). These two examples help demonstrate one of the implications of this hypothesis, which is that if your audience is large and untrained, stronger convention tends to lead to better usage of the system.

Contrast our examples of cars to air traffic. I'm not a pilot, but my understanding is that aeroplanes (and air traffic in general) have a lot of configuration options. Some of this is inherent in the problem space (an entire additional dimension of space), but a lot of it is also to allow skilled operators to more effectively utilise the system. Consider now how auto-pilot changes this equation. Can a non-skilled operator use an auto-pilot to fly a plane? No, I checked. At first glance, it seems that auto-pilot allows us to change the system between configuration and convention, but on further inspection, we realise that it is just another state of configuration. The rule of thumb we can use here is "Do I need a full understanding of the configuration of the system to ensure the convention is doing the right thing?". This question is also immensely valuable as a litmus test in software engineering.

To round out our example section I want to touch on two more complex configuration systems which I hope are useful for what follows. Firstly, an ERP (think SAP). The reason ERP implementations cost many millions is generally that they require large amounts of complex configuration to be fit for purpose. The reason, also, why most ERP projects fail, is because the number of people involved in these implementations (on purchasing and selling sides) who truly understand this complexity tends towards zero, and so timelines and problems are bound to be under-scoped.

Our final example is probably the quintessential example of a complex system requiring complex configuration to realise value: General purpose programming languages. To realise value for a system built from scratch in a programming language generally requires a full understanding of the code written in the language (the configuration). I point out this extreme because it shows us that configuration complexity is a spectrum, and more importantly, that any configuration that smells like coding probably sits further on the complexity spectrum than you might realise at first glance.

Now that we're done with examples, I want to look at some examples. This time, however, we're looking at examples of systems or software when the actual configuration/convention required to use the system is obscured by marketing. The two examples are machine learning, and complex business software (there's a third example that combines these two that I'm not brave enough to talk about).

Machine learning falls into a great space where it can be incredibly useful for certain problems, given the right level of complex configuration, but most of the marketing for companies that make money selling machine learning don't like to point out these caveats. There is only one world in which machine learning can work for you without you having to personally configure it to a tee, and that's the world in which that configuration has been done for you and you have to use the software on its own terms. That is why the most successful machine learning solutions right now tend to be tools such as OCR or speech detection because they are able to force very specific ways of interacting with the system. Contrast these to a fictional/example tool that promises to take doctor's notes and automatically extract patient information from them. In this example, you're forcing the tool to operate based on your conventions, which means you will have to spend time configuring it.

Finally, business systems tend to fall into this trap frequently (true for both vendors selling/marketing their products and business procuring/tendering for solutions). The two most common scenarios in my experience are a) when the system needs to integrate with other business systems to function and no one involved understands how complex that is (a lot), and b) when the business doesn't understand how their business processes map to the system's functionality (and are unwilling to change to fit the system's convention).

What all of this means is that if you're purchasing software or otherwise evaluating a system, do an in-depth analysis of how a) your process will have to change if the system requires convention, or b) how much configuration is required to make it fit. If you sell software, it's your responsibility to ensure your customers understand this, and if you create software, it is valuable to consider where you want your software to sit on this spectrum, especially when you consider factors such as user training or safety/correctness guarantees.