Almost all technical teams experience some degree of technical debt. Although technical debt is a shortcut to achieve quick returns, enterprises often need to spend a lot of money and manpower in order to repair the technical problems that they have to do in order to achieve quick returns. So how do you effectively avoid technical debt so that developers can devote more energy to doing effective work, thereby generating additional value and improving the competitiveness of the enterprise’s products?

Technical debt has many causes, but more of them are due to be in a hurry to finish in a short time that takes a longer work, cause there is no complete design of business logic, etc., makes the products effectively in a short time, but in the long run, it is a unstable bomb, once triggered, the product, are likely to cause irreparable damage to the enterprise. All in all, technical debt can cause a lot of trouble, some of which can even be “fatal”.

What is technical debt?

Technical debt, also known as design debt or code debt


Debt is a metaphor in programming and software engineering. When a developer compromises what should be the best approach in order to speed up software development by switching to a solution that speeds up development in the short term, thereby imposing an additional development burden on themselves in the future. This technical choice is like a debt that, while it may look good in the present, must be paid back 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 as the best way to implement them.


“– Wikipedia

Many people liken technical debt to financial debt, but unlike financial debt, technical debt may not bear interest. For example, when a feature of a product needs to be quickly validated, a product with some technical debt may be a good choice; After verification, when this feature is not needed, it can be removed directly, etc., at which time there may be no interest on the debt. Most of the time, however, this is rare, and even for the sole purpose of verifying the product, technical debt is not recommended. A more dangerous type of technical debt is called unintentional technical debt. Unintentional technical debt is like the bomb hidden in the code mentioned above.

No matter what kind of technical debt is, in the process of future product iteration, developers need to define the boundary of debt and cannot allow the breeding of technical debt. Otherwise, in the process of iteration, they will face more and more difficulties and even have to bear more technical debt. Basically, the more debt you take on, the slower the project will progress and the more difficult the subsequent phases of the project will be.

But be clear, technical debt cannot be eliminated, and you must be prepared to take on technical debt at any time. Because some project scenarios have solutions that address specific problems, but may not be globally effective or optimal, there is an inevitable technical debt problem that must be assumed in other areas of the system. A good team of engineers should be able to minimize the impact of technical debt and reasonable management of technical debt.

As mentioned above, technical debt can be divided into intentional technical debt and unintentional technical debt, and the causes and results of the formation of the two forms of technical debt are different. In some cases, intentional technical debt is better than unintentional technical debt. Intentional technical debt makes the team aware of the problem, so that they can make intentional improvements, etc. Unintentional technical debt may be latent for a long time in the project, which may lead to serious problems. However, unintentional technical debt is inevitable in the project, and it can only be managed or reduced by strengthening coding standards and business understanding in the engineering team.

In addition, the technical debt can be classified into reckless and prudent technical debt. Some prudent technical debt is desirable in the course of a project, but no matter what kind of technical debt it is, it needs to be borne by everyone. Ideally, the liabilities taken on should be those that are intentional and prudent, and those that are unintentional and reckless should be avoided at all costs.

Why care about technical debt?

How does technical debt affect development

In the development phase, developers will inevitably encounter technical debt, should face the technical debt and actively deal with the problem. Although dealing with technical debt may lead to a longer development cycle, in the long run, it is beneficial for developers to deal with technical debt in a timely manner. On the one hand, dealing with technical debt is a process of accumulating technical experience, and on the other hand, timely dealing with technical debt can reduce the possibility of technical debt in subsequent iterations. Every developer should intentionally or diligently avoid inadvertent and reckless technical debt.

How does technical debt affect customers

Although at first glance, technical debt is not related to the customer, and the customer is not concerned with the quality of the product code, the customer just needs to deliver the product on time without increasing the cost. However, a product with unintentional or reckless technical debt often takes more time, energy and resources in the development process, resulting in increased costs and reduced benefits.

How does technical debt affect users

Even indirectly, users are affected by technical debt. They may not care about the amount of work or money required to develop the software, but they do care about its reliable operation and the rapid addition of new features, both of which can be affected by a large amount of technical debt. The happier the user, the happier the customer, and the happier the developer.

Technical debt best practices

The biggest problem with dealing with tech debt is that it can’t really be quantified. This makes it difficult for the development team to keep track of technical debt and allows management to show customers why they should invest more resources and time.

But here are some things you can do:

Stay up to date

It goes without saying that tools, frameworks, and libraries should always be up to date. Not everyone is aware of this, so it doesn’t hurt to emphasize it here.

The document

Documenting everything that needs to be fixed or updated is the most important step to ensure that it is actually fixed and updated.

If technical debt exists, it’s good to know about it and make sure the team or future developers know about it, too. Documentation reduces the amount of work required to locate and fix problems, and if the debt is well documented and even visible at the business level, it can help gain customer recognition and provide additional resources.

Code review

Another powerful tool is to review the code periodically during the sprint. Code reviews can capture potential pitfalls that could lead to problems and find solutions. Code review does take some time, but it is certainly worth it in the context of the overall project.

However, code review has its drawbacks. Developers are often too busy to dig deep into other people’s code, so they only find obvious errors, and nitpicking can cause tension within the team. As such, it can be a powerful tool for reducing technical debt, but it should be used with caution.

Automated testing

Automated testing is a very powerful tool, but it is often overlooked. When automated tests are ignored, they may not be able to detect hidden problems in the code, often resulting in a disproportionate amount of effort and time needed to deal with the product once it is released, which can lead to high or even unmanageable costs. During the development phase, it is necessary to implement test-driven development and write complete test cases to remove many subtle problems in the code, etc.

Agile architecture

Agile architecture has many advantages and is more open to change during the process of building software, which can happen on virtually any project. However, it does require that the code be flexible and maintainable, so agile methods naturally allow developers to keep the code in good shape, which helps prevent large accumulates of technical debt.

Effectively resume

If there is a problem, you should face it, and when the problem is solved, you need to review it effectively. But it should be noted that the purpose of the review is to improve work efficiency, rather than to find someone to carry the pot. The focus of the review should be on understanding the problem and the cause of the problem so that the team can take the necessary steps to prevent the same problem from happening again.

Best practices for managing technical debt

Even if you do all of the above and try to avoid piling up technical debt, there will still be some debt that needs to be dealt with. This is unavoidable, so best practices and processes should be implemented to prevent technical debt from getting out of hand.

High interest (high cost) technical debt is preferred

Not all technical debt is created equal, so priority should be given to issues that need to be addressed within a certain time frame and issues that are not addressed in the first place. The “garbage” that exists in parts of the code that are used and changed a lot is much worse than the “garbage” that exists in parts of the code that are barely used or changed.

High-interest debt is often the core part of a project that plays an important role, and a lot of work is usually done around it and built on it. If this part of the technical debt is not resolved, it will hamper all work and potentially force other parts of the code to incur more technical debt. Therefore, if possible, these issues should be given priority first and everything should be smoothed out later.

Boy Scout Rules

“Always keep your camp cleaner than you found it” also applies to software development: “Submit code better than check it out.” Encourage team members to actively reduce technical debt; For example, when they find code for feature additions or bug fixes, motivate them to refactor that code.

Of course, it can’t be without boundaries, or it could be endlessly time-consuming. However, if you set aside a percentage of each Sprint dedicated to fixing any technical debt the developers find, it can go a long way towards keeping the product as debt-free as possible.

Repay debts while performing valuable customer work

Repairing technical debt throughout the sprint of a project is not a good idea. For one thing, clients often don’t like delays, and to them, it looks as if you’ve spent their time and money fixing your mistake. On the other hand, it also means that you’ve done a lot of work with technical debt, so you may have paid more for the debt than necessary.

It is best to limit the amount of time spent paying off technical debt in each sprint and use it to solve high-priority or sudden problems. Satisfy customers and keep technical debt at manageable levels.

ignore

It is also important to note that not all technical debt should be repaid. Technical debt is not a major issue as the product approaches its useful life, if it is a short-term use or a one-time prototype. These examples are rare, but you can save yourself some time and effort when they do appear.

conclusion

Technical debt is inevitable along with the project, but how to keep it under control is a problem we should think about. The avoidance and elimination of technical debt requires good developers, and people are always the most important factor in software development. As an ordinary code farmers, constantly improve their own is very necessary.

This article is mainly translated from:

TECHNICAL DEBT: EVERYTHING YOU NEED TO KNOW, AND HOW TO MANAGE IT (https://codingsans.com/blog/t)…

By Gabor Zold. TalkingData Robin

Other references:

Technical debt (https://zh.wikipedia.org/wiki.)

The four principles of technical debt governance (https://insights.thoughtworks)…

Resolve technical debt (https://www.infoq.cn/article/…