Whether you’re a tester, or a developer, or a manager, you’ve probably wondered at some point in your life – what makes apps so complex? Where does all the complexity come from?
It’s complex to build, to test, to deploy, to ship a quick bug fix.
All of the above.
The main problem with complexity is that it comes with costs. Complex code is hard to maintain. It is hard to understand. It’s definitely harder to test.
The issue here, is that it’s all in the hands of the developers. If anyone can do something about the complexity of the system, it’s the builders of the system, right?
Complexity comes in all kinds of flavors. But there are really only two we need to know and appreciate.
Essential complexity
The first one is called Essential Complexity. This is the complexity of the problem. For example, if I want to book a flight, I’ll need all the current and relevant information about flights, times of departure and landing, costs of flights. If there is something on the wing.
The problem itself, getting and syncing all this information from multiple sources, is very complex. We should appreciate travel sites more.
It could be that complexity is of scale. Think Facebook for ten people. Like, Zuck and when he had actual friends. The challenge is sharing texts, images and comments. Not something we couldn’t do in the 90s. But support a billion users – now that’s complex!
We can’t really do anything about Essential Complexity. It is what it is.
Accidental complexity
So then we attack the problem. Now it’s our turn: we add Accidental Complexity. Which is the complexity of the solution, not the problem.
It’s not called acceidental for nuthin’.
And now we can enjoy both.
In the solution space, we can, and do, a whole lot of damage. We can choose between different designs. We can use different patterns. We can combine different versions of components and fit them together. We can work towards simple, but many times we just go with the complex design.
Then, new people come in and say: “well, that’s no good. We need to improve/renew/rewrite/upgrade”. And they add more accidental complexity to the already complex beast.
Now, everyone has to make sense of the franken-system. That is of course, hard and painful.
But wait! There’s more!
You want to know something? It’s still a small part of the complexity problem.
Have you ever stopped to think about the code that you and your team are building? Out of the whole application running, how much of it did your team contribute?
Tinsy-winsy-itty-bitty part.
We use servers, libraries, open source code, so we won’t need to write everything from scratch. That’s a good thing. But how much complexity do those dependencies bring?
That means that even if you wanted to reduce the complexity, you’re really out of luck, because most of what’s running (and its complexity) isn’t yours! You’re just there for the ride.
And that’s why everything’s so complex. Most problems we try to solve these days are complex (or they would have been solved already). Then come the solutions and add that accidental complexity on top.
Uncomplexify, please!
So what can we do about it?
First, stop inventing new words. And designs. And ways to write code.
We find simplicity in things we find familiar. Clean code reduces complexity. Simple design does that. Ubiquitous language does that. Refactoring does that.
In the designs that we make, in the code we write, we can control how much complexity we let inside. It really is up to us, in the bits we control. Because all of the rest is really out of our hands.
And once you understand that, it’s not that complex.
For more simple stuff, check out my Clean Code workshop.
0 Comments