Manage Technical debt

Technical debt is widely regarded as a bad thing and it should be avoided or repaid as soon as possible.

Is that what you should do? We don't think so. First, we compare the technical debt with the financial debt, and expound its similarity with the strategic Design (strategic) and its stakeholders. Then, we list all the possible ways to identify the technical debt in the code, which may be of concern to you.

Finally, we describe the different ways in which technical debt can be repaid in a project, and explain the factors that must be considered when you decide on a debt repayment, transfer debt, or just pay interest.

What is technical debt

There are two different ways for developers to implement new features: a quick and messy completion that makes future changes difficult. The other is neat (clean) and sensible, it takes longer to implement but future changes are easier (see also Martin Fowler). However, if the same feature is implemented in a more messy way, with the same functionality and lower costs, then why would the sponsor of the project accept a higher-cost neat implementation? Why would they spend money on automated test coverage? Testing is not a feature and therefore does not deliver business value!

If messy and not-tested code can deliver the desired business value, it will work well for the customer, but it will lead to unmanageable code bases, extremely specialized developers, and ultimately a software product that lacks flexibility. A lot of messy code is likely to cause the entire engineering sector to stagnate (Stand-still).

The analogy of "technical debt"--similar and different from "financial debt"

In 1992, Ward Cunningham used the metaphor of "technical debt" for the first time in communicating this issue with non-tech stakeholders. Low-quality or no automated test coverage can be analogous to financial debt. Such code is like a financial burden that involves all stakeholders-not just developers-that debt can lead to interest payments in the future. The principal is the cost of refactoring the code base to clean design, and neat code simplifies future changes. If the team works in the future on a messy code base, the extra cost of a good code base is interest.

The difference with financial debt is that you don't necessarily have to repay the technical debt. Sometimes it doesn't make much sense to pay it off: Some code is rarely or never read or modified. Therefore, the technical debt also needs to consider the probability of occurrence--the likelihood and frequency that the chaotic code will be contacted in the future? Another difference from financial debt is that the person who pays the debt is not necessarily the original creator of the technical debt, but the developer who then maintains the code base.

Like financial debt, technical debt is not necessarily a bad thing. If you know how to pay, borrowing to buy a house is also a responsible act. But if you know that you can't pay your bills and still buy a lot of luxuries by credit cards, it usually has disastrous consequences. Considering that the software's technical debt may lead to an early release version, and that the organization benefits more than the cost of repaying the technical debt. In finance, borrowing is a good thing if the principal plus interest is lower than the return on investment. For software, this is still true. If you sacrifice your internal quality to get the first place in the market, then you need to get a higher return on the back of the market, but with better internal quality, it's worth it. There are risks, however, because it is difficult to anticipate these gains, and there is a certain degree of uncertainty here.