A programmer lives from deadline to deadline, and deadline to deadline is a common occurrence. He tries to complete as many tasks as possible, often leaving some things “for later”. For many this “then” never comes (because new tasks keep appearing) and poor-quality code has a life of its own, harboring potential problems. The article will talk about technical debt reduction.
Books could soon be written on the subject of technical debt. In essence, it is a product management topic. It’s clear from the title that it’s something left for later. In our case, it is programming. Avoiding it is hard enough. Here’s an example: a website for a customer. Usually, no one sacrifices the front end, because it is the image of the company. They skimp on the back-end and security. They leave it for later when there is money. It is important to properly build the development process, which is the task of a project manager or team. Here is a rough development cycle: idea – layout – architecture – prototype – alpha – beta – testing – release. What can really be sacrificed and what can’t?
From my perspective, 3 solutions:
1) If the debt doesn’t interfere with the process, just drop it.
2) Stop balancing quality and speed, and choose one parameter.
3) Hire a person: an architect, or a planner. So that he correctly evaluates the points, which can be included in future versions. That is he must have at least a rough idea of which functionality at which dates and in which version must be implemented (!).
However, technical debt is not something to be bypassed (everyone has different funding). It also works as an additional incentive.
There are no miracle recipes or secrets here
You need to set aside (gouge out, if you work in a corporate environment) time and get rid of technical debt on a regular basis. You can turn to TETRA™ technical debt reduction for help. Choose only qualified specialists, so as not to make the situation worse.
This can look like anything, for example, you can include debt elimination tasks into your backlog along with business tasks, the form is not important – the main thing is to make it work.
The first thing that will help here is:
- Auto-tests, you have to write them, otherwise everything will turn into “we rewrote the code as it should be, but now the product suddenly stopped working as it should.”
- Logical (and physical) partitioning of the application into services with clear boundaries of responsibility. In this way, technical debt can be eliminated in each service (without affecting the others).
I would only add that sometimes an approach is used as a tool to “force” the allocation of time to eliminate the debt, in which developers do not bother with the technical debt until the product becomes completely unsupportable. Then, with a lot of conflicts, a decision is made to “rewrite everything” and all stakeholders (customer, management, and team) are convinced of the need to allocate time to eliminate the technical debt.