The 8 biggest mistakes when rewriting software systems (that I have seen so far)
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.
Technical Debt, Legacy Code, Maintenance Load
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.
Technical Debt Dilemma
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
Platform team against technical debt: Good idea or nasty trap?
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.
How to communicate technical debt?
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.
Excessive technical debt is almost always an omission of technical management
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.
Technical debt - despite its name - is not a purely technical problem
Technical debt thrives particularly well in environments with certain characteristics. Lack of experience in software development within a team and missing awareness of the importance of good, easy-to-understand code are for example strong drivers. Too much pressure to implement features fast, as well as too much bureaucracy that discourages individual initiative, are other contributors that impact a team and quickly result in technical debt. In a nutshell, people, their skills and their cooperation within and across a team are the key factors for the build-up but also the reduction of technical debt.
Three myths about technical debt
What is technical debt? In a nutshell, technical debt is unnecessary complexity in code. Not to be confused with the essential complexity imposed by business requirements. Unnecessary complexity makes every new feature and every change a little harder to develop than it needs to be. The higher the unnecessary complexity, the harder it is to understand the code, estimate the effect of changes, and test the code. All this slows down further development.