
Complexity is everywhere in our lives. Take driving, for example. It’s hugely complex, mechanically, technologically and cognitively. But we still do it every day. And when we try to oversimplify it, bad things happen. The task’s complexity is why we’re still so far from fully autonomous driving.
In technology, complexity is usually caused by the countless requirements, interconnections, market forces, regulations and, probably above all, changes that we weather as businesses. And it isn’t inherently bad.
When tackling complex problems, we’re taught to break them down into manageable chunks: smaller problems that we can solve one by one. Which is great, assuming we keep in mind the complexity of the bigger picture. Yes, we can break things down to their component parts, but we still need to understand how those components work together to support the whole system.
Of course, where complexity isn’t needed, we should simplify and remove. But as Einstein once said, “Everything should be made as simple as possible, but not simpler.” There is a limit. If we oversimplify, we lose the ability to accurately represent — and more importantly, solve — the problem we started with.
Because complexity itself isn’t a problem to be solved. The issues start with complication: aka poorly managed complexity.
This happens when we oversimplify something. We end up with a solution that’s not a faithful representation of the problem. And that solution therefore cannot fully solve our problem. Our users end up having to find ways to get their job done outside of our solution. We’ve created complication by oversimplifying.
It also crops up when we fail to understand the vital role of each component in a complex system. We have perhaps documented them, and we might have faithfully reproduced them in our solution. But we’ve not really understood the why of them. So we’ve brought all the complication along with us. We’ve made complexity difficult, not easy.
These issues tend to crop up when we jump into the solution before understanding the problem and which parts of it are worth trying to solve. In other words, when we’re not connected to the business case. That’s why we spend so much time upfront to get to the bottom of what’s going wrong. We borrow tools and processes from User Experience, product management and Requirements Engineering to give us the different perspectives and angles we need.
Because without clarity on the business objective and a detailed understanding of user goals and needs, we can slip into the comfort of engineering. It’s easy to focus on the bells and whistles as they reassure us that we’ve got something polished. But there’s no point building the wrong thing well: the feature-rich giant Swiss army knife, when all you needed was a screwdriver.
A well-designed system based on strong strategy can make the complex easy. Let’s focus on embracing complexity: taking the time to understand it and respect it. When we do that, we can remove the unnecessary, the surplus, the complications.