Contemplating Complexity

We’re often taught to reject complexity, and there’s a certain simple, elegant logic to that idea. Taken at face value, it seems like a good idea. Applied mercilessly, less so.

It’s important to be careful when evaluating complexity that you don’t make the situation worse for yourself by eliminating it. To get where I’m coming from, I’ll couch complexity (or its lack thereof) in terms of things you need to be mindful of:

  • Unnecessary complexity
  • Necessary complexity
  • Wasteful simplicity

When we aim to eliminate complexity, the implicit emphasis is on unnecessary complexity. The important takeaway is that complexity, in and of itself, is not automatically a bad thing.

There is a saying, often attributed to Albert Einstein (though the origin is somewhat murky; while he may have said it, it’s not clear whether he coined the term):

Everything should be as simple as it can be, but not simpler.

I often think of this guidance, perhaps even more so now I’m in product management. There is actually a fine path to tread between simplicity and complexity; simplicity can be good, but taken too far it can eliminate choice. Complexity can provide potentially more choice, but at the expense of the common user experience.

Consider, for instance, backups. Let’s say you have all your assets and policies configured within your system. Wouldn’t it be simple, once you’re at this point, to just simply present an interface that has a big green button and a big red button? When you click the big green button, everything starts running automatically, and the green button stays activated. When you need to intervene to do something, or if the system encounters an issue it can’t deal with, the green button is deactivated and the red button is activated. As long as the green button is active, you don’t have to do anything.

This is where the “…but not simpler” part comes in. By crossing that point from “as simple as possible” to “simpler than as simple as possible”, we actually lose functionality and lose visibility into the system. If management want a report on overall system health and KPIs, answering “The green button is still active” might theoretically answer their question. However, it’ll only be an answer in the most abstract of ways. Perhaps most importantly, it assumes that “OK” is a sufficient answer to a nuanced question regarding backup success ratios, performance, KPIs and other potential metrics.

This careful path between unnecessary complexity and wasteful simplicity doesn’t just apply to the technology, either. It also applies to the processes we develop and follow to use the technology. Arguably that means it’s even more important to find the right path when dealing with the processes, since striking the right balance and getting the process right can make up for situations where the technology errs too much on one side or the other (or even alternates between the two).

The interesting thing here is that to get the level of complexity/simplicity right, you have to understand the personas of the people who’ll be following the processes and using the technology. For instance: many years ago, someone in a training course stated that an enterprise backup product was too complex. Their rationale was because at a remote site where it was deployed, the office secretary who had to use it to change tapes found it difficult to use. Now, I’m not dissing office secretaries, but here we get into the persona challenge. Enterprise backup products are not designed to be administered by office secretaries, but technologists.

I’ll draw a non-data protection comparison here: a few years ago, as a team-building exercise, I got behind the controls of a true flight simulator – the sort of one that’s actually used by pilots to practice and learn how to fly passenger jumbos. Neither I, the simulated pilot, nor the simulated passengers survived that experience. But that wasn’t the fault of the simulated plane – it was the wrong persona using it. I.e., me, a technologist with no interest in aviation, versus an actual aviation professional.

The lesson here is a simple one: you cannot achieve the right balance between simplicity and complexity without knowing who you are doing it for.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.