Figure 1: Code Complexity “Let’s build the simplest solution possible.” - But what exactly does simple mean? All too often, it is mistakenly confused with easy. But “simple” and “easy” are two fundamentally different concepts. Rich Hickey picked that apart in his presentation Simple Made Easy. Easy means ’to be at hand’. When a team decides to implement a feature as quickly and easily as possible, it usually means implementing the most immediate solution.

Recently, we were facing the following problem: Most of a team’s work went into bug fixes and resolving urgent issues. Almost nothing else got done. Solutions discussed in such situations usually are: A fixed percentage of the team’s time is used to fix bugs. No fix without a test - for every fix a test must be written Bug bash, one or more sprints where only bugs are fixed in order to get some air again A fastlane for bugs … So anything that will relieve the symptoms and fix the immediate pain.

Here is my personal top 8 of the biggest mistakes made when rewriting software systems: Big-Bang Rewrite. All functionality must first be mapped to the new system before existing customers are migrated to the new system. Martin Fowler’s response: “If you do a big-bang rewrite, the only thing you’re guaranteed of is a big bang.” Put the best people on the new system, everyone else stays with the legacy system. Of course, they feel like they’re on the sidelines.

In this article, we are going to address the terminology clutter and differentiate between the terms technical debt, legacy code and maintenance load. Technical Debt This term is probably the most problematic in that it is often misunderstood and some people have deliberately stopped using it for exactly this reason. The term was originally coined by Ward Cunningham when he was involved in the development of a software in the finance sector.

Perhaps you know the following dialog or have even had it yourself: Product Manager: “We have to get this out as quickly as possible. How do you estimate the effort?” Engineer: " Tough. The code is really complicated by now. We have to clean it up first, at least [significantly more time than expected]." Product Manager: “Can’t we make it simpler?” Engineer: “It could be done somehow, but we have already accumulated so much technical debt…”

Jede Technologie ist nur so gut wie das Problem, das sie löst Ein heiß diskutiertes Thema in jeder Softwareentwicklung ist der aktuell verwendete Tech Stack. Sollte nicht doch das neuste JavaScript- oder Microservice-Framework eingesetzt werden? Schließlich wird es zur Zeit auf jeder Konferenz vorgestellt! Sollte nicht jetzt sofort auf eine neue Technologie gewechselt werden, damit wir auch in Zukunft noch anschlussfähig sind? Nicht selten bildet sich hier eine Front zwischen alten Hasen, welche die bestehenden Technologien verteidigen und neuen Kollegen die Probleme gerne anderes angehen würden.

The situation is usually like this: For a long time, technical debt is not an issue, or it is ignored. Eventually, development slows down and more and more problems arise. Technical debt slowly becomes an issue. Discussions begin about how to tackle it. By that time, so much technical debt has accumulated that single teams are overwhelmed. When refactorings affect multiple teams or are too large for a single team to handle “on the side”, the idea of a dedicated platform team eventually arises.

Why share ? Long-lasting teams will sooner or later end up with more than one application even if they don’t go all the way to microservices. Avoiding duplication is a key issue in software development. Since you can’t access your code in every service without putting it into a shared library, the need for such a library will almost immediately arise. Don’t put everything into one library The most common solution: One common shared library which is used for all the code that may be reused in different services or applications.

Discussions between development and product management about technical debt are good and important, since not every technical debt needs to be paid directly. In fact, what is relevant and what is not is best determined in a joint discussion. However, it is striking that even experienced developers have difficulties in communicating the benefit of reducing technical debt well. Product management often focuses on the costs without recognising the benefits, which naturally leads to a clearly defensive position.

An experienced and well-established team with a high level of trust and mutual respect from development and product management, as well as the necessary seniority and experience, can certainly do this. However, many - if not most - teams are not at that level. There is a lack of seniority and experience. Individual developers feel they are not allowed to refactor. Everything is so urgent that refactoring issues just keep falling to the back of the list.