Hi,

As written on Monday : Small and medium-sized enterprises (SMEs) have no problem with performance.

However, that’s not entirely true. Over the past few years, I’ve worked on many products that were slow. Improving performance would have been positive for the business. In certain areas, like the gaming industry, it was inevitable to be performant. Retention is one of the most important metrics in the industry. But that’s the exception, not the rule.

Performance issues are just the tip of the iceberg in software development for SMEs.

Poor performance is just a symptom. It’s rarely so bad that it’s the problem in the application.

SMEs Suffer from Overengineering

In 2022, I already vented on my blog about how every applicant tells me about microservices . The blog hit a nerve back then. It even got a feature on Hackernews .

And what do I see in the market today? My clients are suffering from microservices again (but not exclusively 😉).

In all my projects, the architecture is too complex. It has been overengineered.

As a result: High maintenance effort, low velocity, and all the typical problems in a distributed system like deadlocks, inconsistencies, or duplications.

And also performance issues because synchronous calls have to be made (must be made) over the network.

But that’s the symptom. Not the cause.

Why we see the same pattern over and over again is hard to say. Probably a mix of Survivorship Bias , hype, and the mentorship crisis .

Most Teams Overdo It

All the SMEs I look after don’t need complex architecture. Products in the SME sector usually cover only one domain.

For one domain, you want to have only one single service. If you don’t do that, you’re designing a distributed monolith. All services are interdependent. You have to make synchronous calls among them.

As a result, you combine all the disadvantages of a monolith and a distributed system. Lose-lose.

Moreover, many products still have to prove themselves in the market. In such a phase of your business, you want to be flexible. You want to try things out, discard them, and rebuild. And quickly. A distributed system doesn’t allow you to do that. The non-functional requirements are exponentially higher than in a monolith.

The Pragmatic Programmer (2022 Edition) p. 448

The paradox in my business last year: All my clients had this problem. And in all cases, I started here. The architecture was overengineered, and I simplified it with them. Because that’s the only sustainable way.

That’s why I’m going to change my positioning.

An External Expert is More Effective in Rebuilding the Architecture

What has surprised me in my work is how quickly I produce results as an outsider. As an outsider, I have the opportunity to point out the sore spots. With my three-day Architecture Discovery Workshop (you know, the one I never advertised, but unlike the Performance Workshop, sold four times ) I always brought about fundamental changes.

And in retrospect, that makes sense. Your current team was the one that designed the complex architecture. Recognizing and admitting to oneself that a fundamentally wrong decision was made is difficult. Every one of our human instincts wants to prevent this realization. As an outsider, I can overcome this point. I can provide the arguments for the management and for the team to recognize the problem and finally address it.

In the coming weeks, I will report more on this. What the strategies are. How to work iteratively on the architecture. What to consider with the employees in such a phase. And much more.

What are your observations in projects? Do you experience architectural overengineering in SMEs? I look forward to hearing about your experience!

Rule the Backend,

~ Marcus