The Holy Grail syndrome
Our industry is harmed by the disease of “There has to be something more!” also called “The Holy Grail syndrome”.
Instead of trying to understand building blocks as they are, we’re trying to mix all of them, hoping that it will magically work and solve our problems.
When we see a simple definition, we can’t believe that it’s such simple, “there has to be something more!”.
And we try to find that even if it doesn’t exist.
For instance, in the recent discussion I had about CQRS, a few people said: “What’s the benefit of the CQRS if it’s just structural pattern?” implying that there has to be more to it, and the typical complexity assigned to it is justified.
Instead of thinking about why the pattern was designed like that and what it enables; we already start thinking about the implementation details. So instead of noticing that allows evolving architecture, focus on business and reduce the risk of change, we immediately throw all the accidental complexity related to the tech stack.
We should learn patterns, use cases as they are, and how to compose them to build bigger structures. Most patterns are simple in a nutshell; what makes them challenging is their interactions with others.
If we don’t understand how to use them but constantly mix them, we’ll end up with a massive hangover.
I noticed that we too often start with complex solutions and then try to simplify them. We should do it the other way round. Start simple and add complexity where needed. Such a way is more manageable, but also…
…less sexy.
Why does it have to be sexy?
In our industry, most people don’t have contact with end users. Moreover, most don’t even have contact with domain experts and can’t make product decisions. As they don’t see the business outcome and can not impact the product design, they focus on what they can feel responsible for. And usually, that’s code. Then they’re toying with the tech stack to feel that they can make impact.
Using a boring stack provides the best business results, but you must see them to enjoy them. If people can’t, then they search for other enjoyments. Plus, we are spoiled by not being accountable for what we do and that odd craftsmanship, clean coders tech bros mambo jumbo.
Of course,
I talked longer on that in The magic is that there is no magic. Or how to understand design patterns. but I’d like to repeat that: start simple, grow big.
Be frank with yourself. Try to avoid complexity where it’s not because you’ll end up with an over-complicated solution, at least if you don’t want to resemble a knight, riding an imaginary horse, making sounds with coconuts.
Cheers!
Oskar
p.s. Of course, we should provide simple solutions, but not simplistic ones. How to make the right decisions? By proper risk management, fast feedback loop and continuous reevaluation of our assumptions. Read more in:
- The risk of ignoring risks
- Why are we afraid of our decisions?
- What do the British writer and his fence have to do with Software Architecture?
p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.