“If we’re going to tackle this now, let’s do it right this time, though.” I heard this exact phrase recently from a team in a fast-growing tech company, expressed with a fair amount of frustration. The team had ambitious goals, which they definitely wanted to achieve. The discussion revolved around the question of how to reach the goal. The team had to decide whether they should make extensive changes to the architecture, including the migration to a new framework, in order to be faster in the long term, or to stay with the current structure.

Why should you do code reviews as a team? ‘WTF? What’s that?’ is something you often hear when working with systems that have been around for a few years and have many developers working on them. **The goal of having regular code reviews as a team is to minimize the ‘WTF?’ moments in the long run by building a common understanding of good code. Nobody writes perfect code. Everyone learns over time.

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.