Backendhance

Finally Good Architecture Documentation

Fri, 23 May 2025 07:58:54 +0200

When developing complex software systems, teams often go through a documentation cycle that follows an almost predictable pattern. The initial euphoria is characterized by ambitious goals: comprehensive documentation should emerge that illuminates all aspects of the system and makes every decision traceable. With fresh enthusiasm, tools are evaluated, templates created, and initial documentation written.

But as the project progresses, neglect creeps in. Development pressure increases, features take priority, and documentation becomes a “nice-to-have” that will be addressed “later.” This phase marks the critical turning point where the foundation is laid for the long-term success or failure of the documentation strategy. This article shows how to prevent a very time-consuming failure.

Anti-Pattern: The Perfect Software Architecture

Wed, 21 Aug 2024 16:14:55 +0200

As a young developer, I was naive and ambitious. I searched for the perfect software architecture, an approach that I could impose on any problem, regardless of industry, scaling requirements, security measures, or users. If you could solve this one problem abstractly, then surely this architecture could be applied everywhere. Right?

This article first appeared in August 2024 as a premium article on Golem.de .

This article explains why the pursuit of the perfect software architecture is an illusion. Current trends and fads often dictate universal solutions that, however, lack the necessary flexibility to survive in the market. This is especially relevant for technical leaders and decision-makers in SMBs. But how can you design an architecture that is flexible enough to adapt to changing requirements?

Surprising Architecture

Thu, 20 Jun 2024 00:00:00 +0000

Hi,

“RCoffee [an internal tool for content production] accesses the test servers via SSH and displays the Tomcat logs”

Wow. That was surprising.

I have been working with this client for a year now.

The application is the market leader in its field, and the current version was developed over 10 years ago.

A lot has accumulated, of course. And when I am hired, the technical debt is usually very large.

Too Big, Too Small, Just Right

Tue, 11 Jun 2024 00:00:00 +0000

Hi,

An old developer joke:

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. – Leon Bambrick

Or another version:

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery – Mathias Verraes

And there are many more:

There are so many variations on the “there are only two hard problems in computer programming…” joke that I’m starting to suspect that programming isn’t actually very easy. – Nat Pryce

How to Get Rid of Microservices?

Thu, 23 May 2024 11:05:12 +0200

In recent years, numerous medium-sized companies have tried the much-touted microservices and found that they are less lightweight than their name suggests – Microservices in SMEs are often overengineering . Now, they need to be deconstructed and transitioned to a more pragmatic architecture. We explain how this can be achieved.

This article first appeared in April 2024 as a premium article on Golem.de .

Don’t worry: The deconstruction and transformation of the architecture is not only labor-intensive but also an opportunity. In software development, there is no one-size-fits-all solution; the appropriate architecture for the software is chosen based on the software’s requirements. This involves gathering the requirements of all stakeholders, which is often not adequately done in many projects. An architectural transformation allows for this to be rectified and reviewed.

SMEs, Steer Clear of Microservices!

Mon, 15 Apr 2024 08:43:56 +0200

For more than a decade, hardly a conference goes by without the topic of microservices. Industry magazines publish numerous articles on the subject, and external consulting firms sell workshops, actively advise on switching to a microservice architecture, and tout its benefits. For many small and medium-sized enterprises (SME), this sounds attractive—what helps the big players so much can’t hurt the smaller ones, right? This is a dangerous misconception.

This article was first published in German as a premium article on Golem.de in March 2024.

Overengineering — the use of unnecessarily complex software — costs SMEs not just a lot of money and time, it also deprives them of their most significant competitive edge against large corporations.

The Cost of Accidental Complexity in Development

Fri, 22 Mar 2024 14:00:00 +0100

In the beginning, IT teams often implement new features quickly, but over time, development tends to slow down. Accidental Complexity is a frequent culprit – this article explains its origins and how it can be mitigated.

This article was originally published in German as a premium article on Golem.de in June 2023.

It’s no secret that systems grow more complex over time, leading to longer development cycles. This is inevitable when dealing with inherently complex problems, known as Essential Complexity. However, in many cases, the implementation of a feature becomes more complex than necessary. Two months for a feature that seemed straightforward? That’s a classic case of Accidental Complexity. It’s frustrating, costly, and avoidable, as we’ll show with some practical examples.

My War on Kubernetes

Tue, 05 Mar 2024 00:00:00 +0000

Hi,

I need to make a confession right off the bat: I’m at odds with Kubernetes.

It’s not Kubernetes’s fault, though. It’s my projects. Or rather, the teams I’m part of.

These are teams with a maximum of 30 software developers, plus a few business people and designers on top. But there aren’t that many developers.

These teams don’t need Kubernetes!

No. To put it more bluntly: These teams can’t handle Kubernetes!

Another Microservice Desaster

Thu, 07 Dec 2023 00:00:00 +0000

Hi,

Microservice Architecture

This buzzword has become a trigger for me. I have written about it often.

Earlier this year, my article Microservices are a Big Ball of Mud trended on Hacker News

The 343 comments on my article clearly show how heated this topic can be 😉 Of course, the rational view on it is different from what I presented in that article. It ALWAYS depends on the context. AppContinuum is an excellent paper offering a reflective view on the subject.

The Microwave With Feature Creep

Thu, 31 Aug 2023 00:00:00 +0000

Hi,

My microwave was broken.

So: I need a new one.

However, I have a little quirk when it comes to buying anything that’s not perishable. I want to avoid making a bad purchase. I’d rather spend more money once than have to buy a new one in two years.

Here, I have to be careful not to fall down a rabbit hole. I can spend hours reading reviews.

But what do I even want to compare?

State Is the Root of All Evil

Thu, 17 Aug 2023 00:00:00 +0000

Hi,

What distinguishes an application from a (mathematical) function?

A function takes an input x and transforms it into an output. If f(x) = 2 * x, then the result of this function for the input of any x is always the same.

There are no side effects. We call this behavior stateless.

But what does this have to do with the question from the beginning? An application goes beyond this. (Almost) every application must work with state. As soon as we have I/O operations in our system, we inherently have state. And often a method call, with the same input, can yield different results at different times. And this is also unavoidable and is in the nature of the task we want to solve.

Sliced Onion Architecture

Thu, 03 Aug 2023 00:00:00 +0000

Hi,

A week ago, Oliver Drotbohm published an expanded idea of the Onion Architecture: The Sliced Onion Architecture .

Most software developers are familiar with Hexagonal Architecture and its extension, the Onion Architecture . The idea (simplified): One decouples their business code from infrastructure code using adapters.

This makes it less likely to create the “Big Ball of Mud” .

What do I see in practice?

Most developers have understood that it’s a good idea not to mix business code with infrastructure code.

Double-Entry Bookkeeping

Thu, 13 Jul 2023 00:00:00 +0000

Hi,

An error in accounting can be costly. Especially in large companies, where there are many transactions, it is easy to overlook one.

And when that happens, I might not even notice it. Perhaps the company is doing much better than the books indicate? Or maybe it’s actually unprofitable?

Merchants in the 13th century recognized the problem. A system had to be found that would make errors less likely. They invented double-entry bookkeeping.

Microservices are a Big Ball of Mud

Thu, 28 Jul 2022 00:00:00 +0000

Over the past years I attended hundreds of interviews. Many candidates proudly told tales on how they develop their projects with a microservice architecture. Often (I don’t want to say “always”, but from my memory I think it actually is “always”) it does not require many questions to see that they used a rocket launcher to kill a mouse. Microservices are hard. Everyone who experienced the pain of operating such an architecture can relate to it. The complexity kills you at one point or the other. You already had to do multiple refactorings of your architecture - because your domains didn’t work out. I wonder - why is this architecture so appealing to developers? And then I remember why I found them appealing 10 years ago.