I wrote an article on technical debt two weeks ago. Although technical debt will accumulate in practice, this concept does not appear frequently in our work. This article will talk about technical debt systematically, so that everyone can avoid knowing it and not knowing why.
1. What is technical debt
Technical debt (English: Technical debt), also translated as technical debt, also known as design debt (design debt), code debt (code debt), is a systematic metaphor borrowed from financial debt in programming and software engineering. Refers to the developers who compromised when they should adopt the best solution in order to accelerate software development, and switched to a solution that can accelerate software development in the short term, which will bring additional development burdens to themselves in the future. This kind of technical choice is like a debt. Although it looks like it can get benefits right now, it must be repaid in the future. Software engineers must spend extra time and energy to continuously repair the problems and side effects caused by previous compromises, or refactor to improve the architecture to the best implementation method.
In 1992, Ward Cunningham first compared the complexity of technology to liabilities. The first time a code is released, it is like borrowing a sum of money. As long as the debt is repaid through continuous rewriting, small debt can accelerate development. But long unpaid debts can cause danger. Reuse of so-so code is similar to the interest on liabilities. The entire department may fall into a dilemma due to loose implementation, incomplete object-oriented design, or other such liabilities.
2. Technical debt performance
Technical debt, like other debts itself, is an overdraft behavior, sacrificing the future to meet some of the current needs. Like other debts, technical debt also carries interest, and over time it will become a time bomb buried in the project. If the product has long-term sustainable development, then the importance of technical debt is beyond doubt.
The essence of technical debt is that the structure of the product hinders progress. The symptoms shown are: unable to easily reconstruct the product to meet market demand; too much dependency between components and poor system structure; too many defects and poor structure; difficult to understand , It is difficult to change.
The consequences of technical debt include repayment of technical debt and waste of time, reduced employee satisfaction and low morale, missed high-quality projects due to resolution of legacy code problems, brain drain, reduced product quality, reduced customer satisfaction, and technical debt restricts innovation capabilities and stifles Creativity and many other issues.
Technical debt is not only a technical debt, it is like a garbage dump. If it is not processed over time, more garbage will be generated around it. Therefore, the "broken window effect" produced will have a great impact on the future project environment. As a result, everyone will gradually lose confidence in maintaining the environment. Therefore, when discussing technical debt, it is not only about technical debt itself. Technical debt will have a great impact on the team's confidence in pursuing quality and everyone's enthusiasm for maintaining the cleanliness of the environment.
Martin Fowler divides technical debt into four quadrants, as shown in the figure below:
3. Reasons for technical debt
●Business pressure: In order to meet the rapid requirements of the business, the necessary modifications are hurriedly released when they are not completed. These unfinished modifications form a technical liability.
●Lack of process and understanding: business personnel do not understand the concept of technical debt, and will not consider its impact when making decisions.
●Insufficient decoupling between modules: The functions are not modularized, and the software is not flexible enough to meet the requirements of business changes.
●Lack of supporting automated testing: leading to encourage quick and risky "Band-Aid"-style BUG repair.
●Lack of necessary documentation: Neither the requirements nor the code have necessary supporting documentation or comments.
● Lack of collaboration: knowledge sharing and business efficiency in the organization is low, or junior developers lack the necessary guidance.
●Refactoring delay: During the development process, some parts of the code will become difficult to control. At this time, it needs to be refactored to adapt to future changes in requirements. The more the refactoring is postponed, the more these existing codes are used, and the more technical liabilities are formed until the refactoring is completed.
●Do not follow standards or best practices: Ignore existing industry standards, frameworks, technologies, and best practices.
●Lack of relevant skills: Sometimes developers lack skills and do not know how to write elegant code.
4. How to "pay off debts"?
1. Visualization of technical debt
Discuss technical debt as much as possible, weigh the pros and cons with the team and stakeholders from the beginning, and clearly inform the impact and solutions. Communicate on an equal footing and understand each other. Make technical debt visible at the business and technical levels.
Two new columns can be added to the property debt of the organization’s balance sheet: short-term technical debt and long-term technical debt. It can also reflect the impact of technical debt on the product by tracking the development rate.
2. Different debts must be remedied
The state of technical debt can be classified into accidental technical debt, known technical debt and target technical debt.
The following principles should be followed when repaying the technical debt:
1) Determine that the known technical debt must be repaid.
2) If accidental technical debt is discovered, pay it back immediately.
3) For each sprint, a certain amount of known technical debt is determined as the target technical debt, which will be repaid in the current sprint.
4) Technical debts that do not need to be repaid are dying products, disposable prototypes and short-lived products.
5. How to avoid "debt"
Instead of repaying the debt and filling the hole later, it is better to avoid technical debt from the beginning.
1. Avoid using outdated technology
Legacy applications, outdated technology, and different platforms and processes can plunge organizations into heavy technical debt, forcing them to postpone basic modernization plans. Kris Beevers, co-founder and CEO of DNS and traffic management technology provider NS1, said: “Technical debt wastes a lot of money and precious time on systems and applications that are not used by modern enterprises. The scale and speed required."
Old assets and old methods are also often full of security vulnerabilities, are difficult to integrate and automate, and are likely to no longer be updated. Beevers pointed out: "Finding talent to manage legacy applications built on complex or outdated code is also an increasingly serious problem. Adhering to outdated technology not only consumes valuable budgets, but also hinders the company's ability to innovate and remain competitive. "
2. Refer to agile practices
More and more organizations are gradually accepting agile software development, which is a series of methods and practices that hand over methods to collaborative, self-organizing teams and cross-functional teams. If this method is strictly applied, agile development enables organizations to avoid technical debt by creating and releasing new products quickly and in an iterative manner. Dodd said: "This process puts new products and new features in the hands of users as soon as possible and gradually." With the delivery of the new version, various improvements and problems have been resolved, which makes accumulation of technical debt unlikely. .
Agile methods recognize that the project is never really completed in the life cycle, and it is never perfect. "At the same time, agile methods focus on... simplified development for capabilities and quality," Dodd said. Important functions are often developed, tested, and put into production frequently. Agile teams may not release a "Big Bang" approach to software, but instead release several major upgrades each year. Dodd pointed out: "This can keep the product developing fairly smoothly, and it can also help users avoid major disruptions."
3. Follow the code specification
Whether to comply with coding standards and whether to follow best practices is also an aspect that affects technical debt. Code specifications play an important role in the R&D project team. The team's unified code specifications help improve code readability and work efficiency. A unified
code specification is the basis of collective code ownership, making pair programming easier to implement, and easier for teams to rotate internally and get promotions. Code specifications and code quality tools help to find technical debt in terms of code quality.
It is not too late. From now on, the repayment of technical debt will be included in the backlog, and the avoidance of technical debt will be the work criterion. I believe that there will be no collapse by technical debt.