I’ve been writing about technical debt for the last two weeks, but the concept doesn’t come up very often in our work, despite the fact that it can accumulate in practice. This article will systematically talk about technical debt, let everyone avoid knowing, do not know why.
What is technical debt
Technical debt (English: Technical debt), also known as design debt (design debt), code debt (code debt), is a programming and software engineering borrowed financial debt system metaphor. When a developer compromises the best solution to speed up software development by switching to a solution that speeds up software development in the short term, thereby imposing additional development burdens on themselves in the future. This technical option, like a debt, may seem beneficial in the immediate future but must be repaid in the future. Software engineers must spend extra time and effort constantly fixing problems and side effects caused by previous compromises, or refactoring to improve the architecture to the best possible implementation.
In 1992, Ward Cunningham first referred to the complexity ratio of technology as a liability. The first time you release code, it’s like borrowing money. Small debts can speed up development as long as they are paid off through constant rewriting. But a long period of unpaid debt poses dangers. Reuse of sloppy code, similar to interest on a debt. Entire departments may be Mired in loose implementations, incomplete object-oriented designs, or other such liabilities.
Second, technical debt performance
Technology debt, like other debt itself, is an overdraft, sacrificing the future to meet some of the needs of the present. Like any other debt, technical debt carries interest and can become a time bomb buried in a project over time. The importance of technical debt is undeniable if the product is sustainable over the long term.
The essence of technical debt is that the structure of the product impediments progress. Symptoms include: the inability to easily restructure the product to meet market demand; Too many dependencies between components, poor architecture; Too many defects, poor structure; Hard to understand, hard to change.
The consequences of technical debt include waste of time due to repayment of technical debt, low morale due to reduced employee satisfaction, brain drain due to missing quality projects due to solving legacy code problems, reduced customer satisfaction due to reduced product quality, technical debt limits innovation ability and stifles creativity, and many other problems.
Technical debt is not only technical debt, it is just like a garbage dump. Over time, if not dealt with, more garbage will be generated around, so the “broken window effect” will have a great impact on the future project environment, and people will gradually lose confidence in maintaining the environment. Therefore, the discussion of technical debt is not only about the technical debt itself, but also has a great impact on the confidence of the team in pursuing quality and the enthusiasm of everyone in maintaining a clean environment.
Martin Fowler divides technical debt into four quadrants, as shown in the figure below:
Third, the cause of technical debt
● Business pressure: In order to meet the rapid requirements of the business, it is rushed to release the necessary changes before they are completed, and these unfinished changes form technical liabilities. ● Lack of process and understanding: Business people do not understand and understand the concept of technical debt and do not consider its impact when making decisions. The decoupling between modules is not enough: the function is not modular, the software flexibility is not enough, and it is not enough to adapt to the requirements of business changes. ● Lack of matching automated testing: resulting in encouraging quick and risky band-aid BUG fixes. ● Lack of necessary documentation: Neither requirements nor code has the necessary supporting documentation or comments. ● Lack of collaboration: Lack of knowledge sharing and business efficiency in the organization, or lack of necessary guidance for junior developers. ● Refactoring delays: During development, certain parts of the code become unmanageable and need to be refacfacted to accommodate changing requirements in the future. The more you postpone refactoring, the more the existing code is used, and the more technical debt you incur until the refactoring is complete. ● Not following standards or best practices: Ignoring existing industry standards, frameworks, technologies, and best practices. ● Lack of skills: Developers sometimes lack the skills to write elegant code.
Four, how to “repay”?
1. Visualization of technical debt
Be open about technical debt as much as possible, and work with the team and stakeholders to weigh the pros and cons from the start, and clearly inform the impact and solution. Communicate on an equal footing and understand each other. Let technical debt be visible at the business level and the technical level.
Two columns can be added to the property debt of the organization’s balance sheet: short-term technical debt and long-term technical debt. The impact of technical debt on the product can also be reflected by tracking development rates.
2. Different types of debt need to be tailored
The status of technical debt can be classified as accidental technical debt, known technical debt and target technical debt.
The repayment of technical debt shall follow the following principles:
1) Determine that known technical debts must be paid.
2) If accidental technical debt is found, pay it immediately.
3) Each sprint identifies a certain amount of known technical debt as the target technical debt to be repaid in the current sprint.
4) The technical debt that doesn’t need to be repaid is dying products, one-off prototypes, and short-lived products.
Five, how to avoid “debt”
It is better to avoid technical debt in the first place than to fill the hole in the later stage.
1. Avoid using outdated technology
Legacy applications, outdated technologies, and different platforms and processes can saddle an organization with heavy technical debt, forcing it to delay essential modernization plans. “Technical debt wastes a lot of money and valuable time on systems and applications that are not built for the scale and speed required by modern enterprises,” said Kris Beevers, co-founder and CEO of NS1, a provider of DNS and traffic management technology.
Old assets and methods are also often riddled with security holes, difficult to integrate and automate, and likely never to be updated. “Finding talent to manage legacy applications built on complex or outdated code is also a growing challenge,” Notes Beevers. “Insisting on outdated technologies not only consumes valuable budgets, but also impedes a company’s ability to innovate and remain competitive.”
2. Refer to Agile practices
More and more organizations are embracing agile software development, a set of methods and practices that devolve methods to collaborative, self-organizing, and cross-functional teams. If this approach is rigorously applied, agile development enables organizations to avoid technical debt by creating and releasing new products quickly and iteratively. “This process gets new products and features into users’ hands as quickly and gradually as possible,” Dodd said. As the new version is delivered, various improvements and issues are resolved, making an accumulation of technical debt less likely.
Agile methods recognize that projects are never truly completed in their lifecycle and are never perfect. “At the same time, agile methods focus on… Simplified development for capability and quality, “Dodd said. Important features tend to be developed, tested, and put into production frequently. Instead of releasing a “Big Bang” approach to software, agile teams may release major upgrades several times a year. “This allows for fairly smooth product growth and helps users avoid major outages,” Dodd said.
3. Follow the code specifications
Compliance with coding specifications and best practices is also an aspect that affects technical debt. Code specification plays an important role in the development project team, the team unified code specification, helps improve code readability and work efficiency. A uniform code specification is the basis for collective ownership of code, making pair programming easier and making it easier for teams to rotate internally and get promoted. Code specifications and code quality tools help identify technical liabilities in code quality.
It’s never too late to mend. From now on, add technical debt payments to the backlog and make it the norm to avoid generating technical debt so that you won’t be overwhelmed by technical debt.