Talk about the definition, impact and management of technical debt

I. Introduction

About this time last year, I thought about seriously discussing the issue of technical debt, which originated from a work arrangement.
This system has been in operation for more than three years. With the development of the business, the system has been connected to more and more business parties and businesses, and it has become more important one after another, so the business side also proposes higher standards for the system. Asked, a senior classmate of the department was immediately arranged to take over the system, but he was strongly complained by this classmate. At that time, I wondered what made the obedience arrangements that have always worked hard to cause such strong emotions? After all, it is more in our hands than this history Older systems abound, so I decided to learn more about the situation.

At the time, it was analyzed that there were several major problems such as outdated technology stack, inconsistent interface, code redundancy, inconsistent code style, unreasonable design and poor performance of core functions, etc. These are common problems, but the performance of this system is more serious. . After analyzing the problem, I decided to start the current development of the system, the former developer, and the former developer and I set up a prominent team to use overtime at night to solve a few major problems that seemed to be at the time. It took nearly three weeks. The process was tortuous, but the effect was It's not obvious. There are some hidden dangers that have caused another quality problem in the system this year, leading to an increase in product operation and maintenance.

The huge technical debt affects the productivity of the software development team and reduces their morale and enthusiasm. The continuous accumulation of technical debt leads to a vicious circle: huge technical debt reduces production efficiency and team morale; at the same time, low production efficiency makes managers launch more functions and leads to the extension of technical debt problems, which further increases technical debt .

With the development of informatization and the Internet, managing old systems and technical debt is a problem facing us veterans.

2. What is technical debt

The famous computer programmer Ward Cunningham first compared the chaos in some software systems to a debt in 1992.

Delivering the first code is like getting into debt. Debt can speed up development, and only through rewriting the code to repay the debt in time. If the debt is not repaid, danger will occur. Every minute spent writing incorrect code counts as interest on the debt. The entire software project may come to a halt due to unmerged code deployment, object-oriented design, or other debt issues. —— Ward Cunningham (Ward Cunningham)

It is very similar to financial debt. In order for a person or organization to obtain a loan from a financial institution for rapid development, the price is to add interest in addition to the principal. If he is able to repay regularly, the debt he owes is acceptable and will not cause further problems. If he fails to repay or is late, he will be punished with interest. As the number of non-repayments increases, the penalty Interest also increases, and then bankruptcy may be caused due to accumulation of debt.

Robert Nord of Carnegie Mellon University Software Engineering Institute (SEI) put forward the concept of "Tech Debt Landscape" in "The Future of Managing Technical Debt".

(Figure 1: From Robert Nord "The Future of Managing Technical Debt")

The technical debt panorama mainly analyzes the impact of technical debt on software systems from two directions: maintainability and evolvability. At the same time, it analyzes the impact of technical debt on the software development process in combination with the visibility of problems. influences.

The technical debt panorama analyzes the scope of technical debt from the perspective of visibility. For example, defects and unimplemented features cannot be called technical debt, because they obviously affect the value of software products and can generally be resolved quickly; technical debt is Invisible parts, such as unreasonable architecture design, poor code quality, and lack of testing or documentation. Defects are often symptoms of technical debt.

In addition, in order to better understand technical debt, SEI researchers spent more than a week discussing a working definition and core concepts of technical debt, describing systems, functions, defects, symptoms, originality, inferences, software deliverables, and Contextual relationship.
(Figure 2: The conceptual model of technical debt comes from Robert Nord's "The Future of Managing Technical Debt")

3. The composition of technical debt

Many people become disillusioned when they hear of technical debt. Like financial debt, technical debt is not always a bad thing. Debt gives us capital to invest before we make money. Taking shortcuts when bringing products to the market allows us to test the business model at a lower cost and discard the code when we find that the code is not good.
Usually the introduction of technical debt is to deliver software products in a shorter time, thereby making compromises in architecture, code, testing and documentation, so that the software products can reach users and obtain feedback as soon as possible. The biggest advantage of this is to make software products run quickly, rather than more perfect design and documentation. After all, users want to see usable software products, they don’t care about the design or quality inside. This is especially true for products developed for C-end users. Time is life, and they may be on the market sooner. Only by surviving can there be room for the next step.

The godfather of software development, Martin Fowler, author of "Refactoring" and "Enterprise Application Architecture Patterns", believes that the interest generated by technical debt refers to the need to pay more in future research and development due to hasty design decisions. In the face of technical debt, the profit can be paid continuously, or it can be paid in one lump sum through reconstruction. The bad smell in the code is also technical debt, a kind of reckless debt that makes the problem worse, and then divides the technical debt into quadrants:

(Figure 3: Technical Debt Quadrant from Martin Fowler’s "Technical Debt Quadrant" 》)

The reason for the introduction of technical debt, SEI's research found that most developers consider the architecture choice. Architecture choices and their design influences often last for many years, and are difficult to plan and retrofit, and the cost of retrofitting is extremely high.

(Figure 4: Coding Frequency for Open-Ended Questions from Neil Ernst's "A Field Study of Technical Debt")

There are many different types of technical debt, 1,000 developers have a 1,000 Hamlet. For this reason, SEI researchers conducted a research survey and found that poor architectural choices, overly complex code, and lack of code documentation are the three most common types of technical debt.

(Figure 5: Ranking Sources Of Technical Debt from Neil Ernst's "A Field Study of Technical Debt")

4. How to manage technical debt

In most of our business development scenarios, the software development team has the responsibility to quickly provide value to customers. Technical debt is inevitable, so managing technical debt is a problem that every practitioner must face, and adopt a diligent and pragmatic attitude Dealing with technical debt is very important.

Team consensus prevents technical debt

Steve McConnell, author of The Code and Rapid Software Development, divides technical debt into two categories that are related to the team: unintentional and intentional.
1) Unintentional technical debt: low-quality code was written due to lack of experience.
2) Intentionally generated technical debt: According to the current situation, the design and selection may be able to solve the current problem quickly, sometimes it becomes awkward.

People understand the technical debt of the development team. Development teams must understand technical debt, its various aspects and types, and the impact of debt on their projects. If you want everyone to understand technical debt, make technical debt visible, develop a habit, and communicate and negotiate regularly.

Mathias Verraes suggested in the article "Technical Debt Wall: Making Technical Debt Nowhere to Hide" to choose a wall where the team works, make sure it is publicly visible, and label it "technical debt wall". Draw a beautiful and vivid logo and make sure there are post-it notes and markers around.

(Figure 6: The Wall of Technical Debt comes from "The Wall of Technical Debt" by Mathias Verraes)

Process support to repay technical debt

Employment-related processes can help development teams avoid accumulation of technical debt. Typical examples of such methods are the review process (such as code, design, architecture, and test reviews) and architecture management (such as to ensure that the code conforms to the expected architecture and design). However, the process used must be pragmatic: stubborn and difficult to follow the process will prevent the team from fully following them, and lead them to seek shortcuts in the process of persistence.

The accumulation of technical debt cannot be avoided only from the process. Ryan D proposed in the article "You don't need to stop shipping features to fix technical debt" that all tasks should be classified, at least divided into functional improvements, planned tasks, Delivery capacity and unplanned work. By categorizing work into these four areas, it should be easier to communicate the value of work, and it will be easier to free up time to deal with technical debt issues. And allocate time reasonably in the above four categories, and determine the correct time allocation ratio together with stakeholders; if there is no participation of stakeholders, the allocation ratio cannot be successfully determined.

BMC columnists Stephen Watts and Joe Hertvik proposed six steps to eliminate technical debt in the article " Technical Debt: The Ultimate Guide ":

(Figure 7: 6 Steps: Removing Cruft & Technical Debt From Stephen Watts and Joe Hertvik's "TTechnical Debt: The Ultimate Guide)

1. Record and track debts-record all code and designs that developers believe are problematic
2. Categorize technical debt-classify technical debt into categories and treat them as tasks to be completed.
3. Evaluate the impact of technical debt-let everyone know the impact of debt and decide whether to put it in the iteration
4. Publicize technical debt-make technical debt public and transparent
5. Plan to eliminate technical debt-communicate with stakeholders the elimination plan of technical debt, and inform that the delivery of new features may be affected by eliminating technical debt.
6. Eliminate technical debt as soon as possible and often-arrange technical debt elimination regularly

V. Summary

Typically, teams work on projects that have accumulated a large amount of technical debt. In this case, it is unwise to ignore the debt advance, because it may lead to technical bankruptcy of the project. On the other hand, it is not feasible and practical to stop developing new features for a few months and instead focus on paying off technical debt. Under these circumstances, a balanced development model is required, debt repayment steadily, and the progress of functions and software availability is maintained as much as possible. The decision to repay technical debt must have the following factors:

• It improves the speed or quality of output. For example, redoing this build configuration will cut our delivery time by half and double the deployment frequency.
• Delays result in high costs and cause tight schedules. For example, if we do not solve this problem now, it will directly affect customers, profits or revenue.

Six, reference resources

• BMC Blog: Technical Debt: The Ultimate Guide - Stephen Watts, Joe Hertvik
• SEI Insights: A Field Study of Technical Debt - Neil Ernst
• SEI Insights: The Future of Managing Technical Debt - Robert Nord
• SEI Insights: Automatically Detecting Technical Debt Discussions with Machine Learning - Robert Nord
• SEI Insights: Managing the Consequences of Technical Debt - Ipek Ozkaya
• Technical Debt - Martin Fowler
• Technical Debt Quadrant - Martin Fowler
• Technical Debt Wall: Letting Technical Debt Be Invisible-Mathias Verraes
• Pragmatic Technical Debt Management -Tushar Sharma
• Technical debt is like Tetris: how do I fix it by modifying the code? -Eric Higgins
• The delivery of functions cannot be stopped, how to solve the remaining technical debt problem? -Ryan D

about us

A well-educated, thoughtful, and principled team, no matter how powerful it is in combat or its beauty.
Author: Wang Yun - middle-aged farmers extra baggage incompetent code