Technical debt. What are my obligations?

Let’s imagine Jake — spherical programmer in a vacuum. Jake needs to be responsible for respecting the deadlines, to listen to the PM, not to set a bunch of crutches because it’s a quick option. And once happened something unexpectable. Jake sold his soul to the devil and took his technical duty.

So. What is the technical debt?

Let me introduce Ward Cunningham — the inventor of the wiki engine, extreme programming and a lot of good things. Also, he is an author of the “technical debt” term (1992). The idea of the term — is the code you are working on should reflect your current understanding of how your program should work.

Like financial debt, technical debt forces us to pay interest, expressed in the form of additional costs. We will be using it’s in future, because we choose quick and dirty development now.

Varieties of technical debt:

1. Conscious (intentional) — the programmer refuses from code flexibility or from covering the code with tests, gaining the time.
2. Unconscious is the inexperience of the programmer in using programming language constructs or using frameworks and platforms.
3. Technological — delay with the update of the platform version and frameworks.
4. Architectural — need to rework the architecture for new requirements.

Reasons that lead to technical debt: business pressure, lack of understanding of the consequences of technical debt, lack of tests and documentation, interaction between team members, long-term simultaneous development in several branches, deferred refactoring and competence.

Technical Debt Life Cycle.

Comparative characteristics of the acceptance and rejection of technical debt:

Let’s sum up the results:

1. If you need to gain the time technical debt could be your friend. But you should be careful.
2. The best option is to avoid debts, but not necessary that you will succeed.
3. Technical debt reduces productivity, so try to get rid of it as quickly as possible.
4. Analyze technical debt and build work with it on different levels.
5. Explain to the client why it is important to allocate time to work on technical debt.
6. Do not confuse technical debt with the ordinary disorder.

So, since that time Jake knows that technical debt is not about poor code. Bad code is bad code, and technical debt can result from the work of good programmers under unrealistic project constraints. It’s a reality for all software teams. Nobody avoids it entirely — the main thing is to keep it from spiraling out of control.