Unimpressive Simplicity Is Quite Impressive

I very often receive surprised-discontent faces from fellow engineers after I show them potential solutions to some highly contended problem in the team. It always turns out to be that they are not necessarily not convinced that this would solve the problem but rather surprised that the solution is simple. Their intuition tells them that simple means easy, and the problem at hand cannot be easy. Our engineering training that hard problems require complex solutions and have to involve a bunch of design patterns has made it difficult for our minds to accept a solution that does not utilize a few dozen concepts.

First, we have to understand, once again, that simplicity does not equal difficulty and that simplicity IS hard. Getting to a simple solution requires multiple iterations over multiple complex solutions and digging deeper into the problem to simplify the design. The more you understand the problem, the simpler your solution will be. It goes the other way, too. Usually, when I see a very complex solution, it indicates that this engineer does not understand the problem well enough.

I should define my view of simplicity for the purposes of this discussion. A simple system is a system that can be understood by anyone with minimal domain knowledge^[1]. In my opinion, more engineering is less business^[2]. If you start from the technical aspect, you cloud your view of the business aspect. Why? Because you will try to look at the business from the lens of design patterns and SQL schemas. You will be trying to forcefully fit the business into the boxes of the few design patterns you have present mentally, which tends to complicate things, and not get the boxes and try to fit the use cases in them.

On the topic of design patterns, the most crucial part of design patterns is the patterns, not the design. Design patterns are solutions for common problems and not common solutions for problems. You need to find the problem first and then use the design. It is all about finding problem pattern ^[3]. I usually refrain from teaching design patterns to beginners (or even mid-level engineers) and prefer to teach them to come up with similar solutions on their own, which helps them to set up their mindsets to start with the problem, not the solution.

Despite this rant about design patterns and simplicity, why are engineers not satisfied with a simple design when someone else comes up with one? I call this the dilemma of pride and engineering complexity. It would not sound as cool to say I solved a problem with a few if statements in a Python file compared to saying I solved it by implementing an event-driven system in half a dozen micro-services.

However, on the contrary, it is more challenging to come up with a simple solution. It is always much easier to complicate things. A little misunderstanding here and there can go a long way in complicating your design. Simple designs are what we should be proud of because unimpressive simplicity is quite impressive.