Resolve technical debt

Original article: http://www.infoq.com/cn/news/2009/10/dissecting-technical-debt

The term "technical debt" is developed by Ward cunnheim
For the first time, it indicates that the development team selects an easy-to-implement solution from the perspective of short-term effects during design or architecture selection. However, in the long run, this solution has a more negative impact, that is, the debt owed by the development team. Agile experts give their views on what the technical debt is and how to classify it.

Martin Fowler
The following definitions are considered to best demonstrate technical debt.
Meaning:

Technical debt is similar to financial debt, which also generates interest. The interest here is actually the consequence of more efforts in future development due to reckless design decisions. We can choose to continue to pay interest, or by restructuring the previously reckless design to pay the principal in one lump sum. Although one-time payment of the principal requires a price, it can reduce future interest.

Steve McConnell
Technical debt is divided into two types
:

• Unintentional
  -Due to lack of experience, junior developers have compiled code of poor quality.
• Intentional
  -- The team selects the model based on the current design rather than the future. This method may quickly solve the current problem, but it is very poor.

Uncle Bob
In addition, sometimes people regard bad taste as technical debt, but this is wrong.
He said:

Bad taste is not technical debt. Bad taste is bad taste. The evaluation criteria of technical debt are true project constraints, which coexist risks and benefits. The appearance of bad taste is never a result of reason, but of laziness and layman. In the future, there is no chance to repay it. Bad taste always means loss.

Uncle Bob said that technical debt keeps people in mind and keeps code clean, as if a person needs to stay vigilant when carrying a huge mortgage debt. He also said that once the team decides to adopt technical debt, it means that keeping the code clean will become unprecedented. If this is not the case, the situation will soon become terrible and the cost of repaying these debts will become larger and larger.

Martin Fowler believes that bad taste is also technical debt, but it is just another form of technical debt. He thinks that bad taste is a negative effect (Reckless
), Relative to the careful (Prudent
) Debt, bad taste will make the problem more serious. He added the intention (Deliberate
) And unintentional (Inadvertent
In this way, technical debt is divided into four quadrants.

Martin uses the following example to divide technical debt into four quadrants:
:

1. Intentionally or not
   -- The team does not have time to design, but only provides a hasty solution, which lacks the foresight of quality.
2. Careful, deliberate
   -- Although there are many known defects, the team must deliver the product now and be aware of the consequences.
3. No consequence, no intention
   -- The team does not know the basic design principles, let alone the bad taste introduced.
4. Careful, unintentional
   -- Teams with excellent designers are prone to this situation. The solutions they deliver are of commercial value, but they do not understand what is the best solution after completing the solutions.

To sum up, technical debt problems will inevitably exist in actual projects, which cannot be eliminated. However, the key to the problem is that no consequence-based debt should be introduced, because it will continuously produce bad taste, it is also difficult to deal.