The History and Future of Technical Debt

Since Ward Cunningham put forward the concept of technical debt in his blog in 1992, the metaphor of technical debt has been used to this day and has always been the focus of attention in the industry because it perfectly expresses the impact of legacy technical problems. Nowadays, major companies have started to improve the effectiveness of research and development in order to establish the ability of continuous delivery and respond quickly to the market changes, technical debt is a key factor that can't be ignored.

The Category of Technical Debt

Source: DevOpsGroup

Martin Fowler classifies technical debt into four different quadrants according to the causes of technical debt: Reckless/Prudent/Deliberate/Inadvertent.

• Prudent and Deliberate

This scenario is common and is a major source of known technical debt. In order to get the product to market quickly and get more revenue, the team usually will choose a faster solution with lower development cost and shorter time, but the solution is not optimal and may only be temporary. However, the team has made a detailed evaluation of the technical choices and understood the impact that the technical debt would have on the product and architecture. The consequences are measurable, and the improvement plans in the future even have been arranged.

• Reckless and Deliberate

Compared to the last category, the team knows that the current solution is not the optimal choice, but the current business requirement is the first priority and no detailed analysis of the current solution is done because of the urgent time. So the possible impact on the legacy technical debt is unknown, and even the specific problems that arise may be unknown.

• Reckless and Inadvertent

This usually happens because team members' perceptions are not yet sufficient to determine whether the current choice will have adverse effects. This type of technical debt represents a high percentage overall, perhaps even more than the first type of technical debt mentioned above. No matter what kind of team, staff turnover is inevitable, different people have different experiences and cognitions, so the solutions chosen when implementing the same function are different, too. Although it is possible to reduce cognitive differences between different team members through some social activities like code reviews, it is often not very effective to avoid technical debt in this way.

• Prudent and Inadvertent

This kind of technical debt seems incomprehensible. Since it is prudent every time, why there are inadvertent mistakes. However, it is true that this technical debt is unavoidable and happens all the time. For example, a team chooses a technical solution based on current experience and even some of the best practices in the industry, but with the improvement and development of the technology, the solution was chosen shows some drawbacks and problems. These outdated technical solution designs and frameworks will become technical debt.

The Influence of Technical Debt

Source: Intetics

Regardless of the above reasons, once the technical debt is created, it will more or less affect the software system. None of these technical debts will show obvious problems in the short term, but during the long-term iteration of the project, as the technical debts continue to increase, the maintainability of the software system will plummet, followed by a decline in quality, which poses a very big problem for subsequent product development.

• Declining product quality and frequent production accidents

This is the biggest and most immediate impact, as technical debt continues to grow, software systems can become super fragile. This fragility is mainly caused by poor architectural design or code design, regardless of whether a well-defined microservices architecture or a monolithic architecture was initially chosen. The technical debt keeps breaking the design principles, making the principles cease to exist, and no one can figure out the relationship and responsibilities between the system components. When some of these components are modified, others are inexplicably affected, and this issue is usually be found after launch, leaving the entire team in a cycle of constantly putting out fires.

• Poor system maintainability and inefficient development

If a software product can still respond well to market changes after 5-10 years, it means that the design of the software is evolving and has strong vitality. On the contrary, if a software has become unmaintainable after several years of development, with the increase of technical debt, it can only be pushed down and rewritten. This unmaintainability own to the ever-increasing stack of technical debt, which continues to increase the complexity of the system.

How to Avoid and Solve Technical Debt

After understanding the causes of technical debt above, it is clear that it is impossible to completely avoid the creation of technical debt. Products are evolving and technologies are being updated. Once the code is written, it will cost extra to maintain. Coupled with changes in team members and loss of context, it is difficult to keep the system in a 100% healthy state all the time.

However, we can analyze how to avoid and solve technical debt based on its causes. We can try the followings:

Source: Freepik

• Routinize the solving of technical debt

The R&D team should guard the architecture as much as the product staff treats the product, and the architectural health is as important as the product quality. In the daily development of the project, in addition to the business requirements of the product, a part of the work should be planned for the optimization of the architecture, fixing those technical debts for which solutions are known and available, so that the responsiveness and product quality of the software system can be continuously guaranteed.

• Clarify technical specifications and strengthen management

Firstly, technical specifications and standards for the team need to be established so that every decision is informed. Secondly, strengthen the management of the process and establish an architecture review committee to review the modification of the architecture to avoid problems on the one hand and improve the specifications and standards according to the problems on the other.

In the book "Building Evolutionary Architectures" by Neal Ford and Rebecca Parsons, the concept of "Architecture Fitness Function" is introduced. When the team has technical specifications and standards, they can build an architecture fitness function to check and constrain architectural changes or code modifications, helping us to detect and avoid the creation of new technical debts.

• Continuously monitor technology trends and plan the evolution of the architecture in advance

With the development of technology, many technologies that were considered advanced a few years ago have shown some drawbacks and are gradually being replaced by new technologies. The R&D team needs to keep paying attention to the technology trend and explore whether there are better solutions. Paying attention to new technologies does not mean blindly pursuing new technologies. First of all, it is necessary to clarify what problems cannot be solved by the existing technologies, and consider where its drawbacks are and whether it has a great impact when choosing a new technology.

• Technical Debt Visualization

Visualization is often the most direct way to help teams identify and highlight problems very quickly, and no words can match the visual impact. But it should be noted that the granularity of technical debt can be large or small, and the priorities are different. Not all technical debts need to be repaired immediately. In some cases, technical debts are created because of the quick pursuit of the market value of products, so constant trade-offs are required.

The team needs to visualize the technical debt in a timely manner, determine the quadrant of the technical debt, determine the priority, and transfer the status of the technical debt through the internal process, which can be solved by the above method.