Oskar Dudycz

Pragmatic about programming

The Holy Grail syndrome

2023-06-01 oskar dudyczEvent Sourcing


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.

Don’t be a Coconut Architect!



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:

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.

👋 If you found this article helpful and want to get notification about the next one, subscribe to Architecture Weekly.

✉️ Join over 5600 subscribers, get the best resources to boost your skills, and stay updated with Software Architecture trends!

Event-Driven by Oskar Dudycz
Oskar Dudycz For over 15 years, I have been creating IT systems close to the business. I started my career when StackOverflow didn't exist yet. I am a programmer, technical leader, architect. I like to create well-thought-out systems, tools and frameworks that are used in production and make people's lives easier. I believe Event Sourcing, CQRS, and in general, Event-Driven Architectures are a good foundation by which this can be achieved.