The post has been translated automatically. Original language: Russian
Technical debt is discussed either as a disaster or as something that will be thought about later. Both are incorrect. Debt is a normal tool: you take speed now in exchange for additional work later. The problem starts where no one counts the percentages.
Debt can be different, and decisions are also different.
A conscious duty. We know that the solution is temporary, we know why, and we know when we will return. This is the healthiest option.An unconscious duty. We did our best, and then we found out what was better. He learns by experience, but is not treated by discipline.Debt from changed requirements. The code was correct for the previous task. It's not anyone's fault, but you'll have to rewrite it anyway.Debt from negligence. They knew how to do it, they did it differently, they didn't write it down. The only type who is not justified by anything.It is useless to mix them in one conversation: the first type is planned, the second trains the team, the third is inevitable, and the fourth needs to be stopped by the process.
How to understand that debt has become expensive
The evaluation of simple tasks began to grow. A change in one place requires edits in the other three. There are sections of the code that no one but one person wants to touch. Bugfixes regularly lead to new bugs.
Onboarding a new developer takes weeks instead of days. The team increasingly responds, "it's easier to rewrite than to fix." The third and fifth signs are the most significant. They mean that no one has the whole system in their head anymore.
What really works
Write down the debt in the same place where the tasks live, and not in a separate forgotten document. An unfixed debt becomes folklore after six months. Link refactoring to tasks that are already included in this code. A separate "sprint for technical debt" almost always loses the fight against priorities. Formulate the cost in the language of business. Not "bad architecture", but "each new integration takes three weeks instead of three days". Distinguish between debt in hot and dead areas. The perfect code in a module that no one has touched for two years is not needed by anyone. To agree that part of the debt remains forever. Giving it all back is also a form of perfectionism.
The main idea
It is not the duty itself that is dangerous, but its invisibility. A team that knows where its corners are cut and how much it costs manages the situation. The team that finds out about this at the moment of production failure only reacts. And how do you record the technical debt: in the backlog, in the comments to the code, or is it based on the memory of the team?
Технический долг обсуждают либо как катастрофу, либо как что-то, о чём подумают потом. И то, и другое неверно. Долг это нормальный инструмент: вы берёте скорость сейчас в обмен на дополнительную работу позже. Проблема начинается там, где никто не считает проценты.
Долг бывает разный, и решения тоже разные
Осознанный долг. Мы знаем, что решение временное, знаем почему, и знаем, когда вернёмся. Это самый здоровый вариант.Неосознанный долг. Сделали как умели, потом узнали, что бывает лучше. Учится опытом, не лечится дисциплиной.Долг от изменившихся требований. Код был правильным для прошлой задачи. Никто не виноват, но переписывать всё равно придётся.Долг от небрежности. Знали как надо, сделали иначе, не записали. Единственный тип, который не оправдан ничем.Смешивать их в одном разговоре бесполезно: первый тип планируется, второй обучает команду, третий неизбежен, а четвёртый нужно останавливать процессом.
Как понять, что долг стал дорогим
Оценка простых задач начала расти. Изменение в одном месте требует правок в трёх других. Появились участки кода, к которым не хочет прикасаться никто, кроме одного человека. Багфиксы регулярно приводят к новым багам.
Онбординг нового разработчика занимает недели вместо дней. Команда всё чаще отвечает «это проще переписать, чем поправить». Третий и пятый признаки самые показательные. Они означают, что систему уже никто не держит в голове целиком.
Что реально работает
Записывать долг там же, где живут задачи, а не в отдельном забытом документе. Незафиксированный долг через полгода становится фольклором. Привязывать рефакторинг к задачам, которые и так идут в этот код. Отдельный «спринт на техдолг» почти всегда проигрывает борьбу с приоритетами. Формулировать стоимость на языке бизнеса. Не «плохая архитектура», а «каждая новая интеграция занимает три недели вместо трёх дней». Различать долг в горячих и в мёртвых участках. Идеальный код в модуле, который никто не трогает два года, никому не нужен. Договориться, что часть долга остаётся навсегда. Возвращать всё это тоже форма перфекционизма.
Главная мысль
Опасен не сам долг, а его невидимость. Команда, которая знает, где у неё срезаны углы и во сколько это обходится, управляет ситуацией. Команда, которая узнаёт об этом в момент отказа продакшена, только реагирует. А как у вас принято фиксировать техдолг: в бэклоге, в комментариях к коду или это держится на памяти команды?
Share
