The post has been translated automatically. Original language: Russian
Problem
"Let's do it faster now, and we'll finish it beautifully later" — probably everyone who has ever sat in a room with a product a week before the deadline has heard this phrase. And you know what? Sometimes it's really a normal decision. And sometimes it's the beginning of a long story, at the end of which a simple task suddenly takes three sprints, and no one can really explain why.
Technical debt is not about "bad code" or an abstract engineering quibble. This is a real debt, just not in money, but in time. Like a loan, it has a body—the volume of what will have to be redone sooner or later—and interest rates that grow with each new crutch on top of the old one. The only difference is that the bank loan is visible on the balance sheet, but the technical debt is not. He just accumulates somewhere in the code and one day shoots out the question "why did it take three weeks again?".
The problem is that developers usually explain this in their own language, for businesses it sounds like complaints, not as a risk. As a result, the debt either accumulates for years and no one touches it, or at some point they try to "clean it up" in one huge refactoring sprint - and this scares everyone, because it is unclear when it will end and what will happen at the exit.
Three types of debt
• Consciously justified — the team deliberately cuts corners for the sake of market entry speed. It's fine if the solution is documented.
• Deliberate unjustified — the corner is cut simply "because it's easier now", without real urgency. This is where problems are most often born.
• Unconscious — the team doesn't even know that the decision was a compromise. It is detected during a code review, onboarding, or a sales incident.
How to measure what is "not visible"
Until the debt has turned into figures that are understandable to a non-developer, it will not be taken seriously. Not because the business is stupid or inconsiderate, but because "the code has become dirtier" is not an argument on the basis of which a decision can be made. Here's what works:
• Lead time for tasks of the same complexity class increases over time, which means that the debt also increases.
• Share of time for bugs vs. the new functionality — an increase in the share of "fire extinguishing" — is an alarming signal.
• Onboarding the new developer's time until the first significant commit.
• The frequency of incidents related to a specific module, rather than to the system as a whole.
Practical steps
1. Keep a debt register — a board or label in the backlog for each conscious "let's do it quickly", with an estimate of the refund price.
2. Agree on a "budget" for debt in advance — for example, 15-20% of each sprint for technical tasks.
3. Link debt repayment to business events: "refactor the payment module before connecting a new provider" sounds more convincing than "it's time to rewrite it."
4. Evaluate technical tasks in the same coordinates as features — in the expected time savings in 3-6 months.
5. Do not sell refactoring as a one—time promotion - the system percentage of time lasts longer than the heroic "purity sprint".
Conclusion
In fact, the whole trick is to stop fighting — "developers against business" — and start talking in the same language: speed, money, risks. The task of engineers here is not to convince someone that debt is bad — everyone suspects it anyway. The task is to provide specific figures that can be used to make a decision. And the task of management is to leave space in advance to repay the debt, and not heroically extinguish the fire at the very moment when the "finish later" finally comes. Because it always comes.
Проблема
«Давайте сейчас сделаем побыстрее, а красиво — потом доделаем» — эту фразу слышал, наверное, каждый, кто хоть раз сидел в комнате с продактом за неделю до дедлайна. И знаете что? Иногда это правда нормальное решение. А иногда — начало долгой истории, в конце которой простая задача внезапно занимает три спринта, и никто толком не может объяснить, почему.
Технический долг — это не про «плохой код» и не абстрактная инженерная придирка. Это самый настоящий долг, просто не в деньгах, а во времени. У него, как и у кредита, есть тело — объем того, что рано или поздно придется переделать, — и проценты, которые растут с каждым новым костылем поверх старого. Разница только в том, что банковский кредит виден в балансе, а технический долг — нет. Он просто копится где-то в коде и однажды выстреливает вопросом «а почему это опять заняло три недели?».
Проблема в том, что разработчики обычно объясняют это на своем языке, для бизнеса это звучит как жалобы, а не как риск. В итоге долг либо копится годами и никто его не трогает, либо в какой-то момент его пытаются «разом зачистить» одним огромным рефакторинг-спринтом — и это всех пугает, потому что непонятно, когда он закончится и что вообще получится на выходе.
Три типа долга
• Осознанный оправданный — команда сознательно срезает угол ради скорости выхода на рынок. Нормально, если решение задокументировано.
• Осознанный неоправданный — угол срезан просто «потому что проще сейчас», без реальной срочности. Именно здесь чаще всего рождаются проблемы.
• Неосознанный — команда даже не знает, что решение было компромиссом. Обнаруживается на код-ревью, онбординге или инциденте в проде.
Как измерить то, что «не видно»
Пока долг не превратился в цифры, понятные не-разработчику, его не будут воспринимать всерьез. Не потому что бизнес глупый или невнимательный, а потому что «код стал грязнее» — это не аргумент, на основе которого можно принять решение. Вот что работает:
• Lead time на задачи одного класса сложности — растет со временем, значит, растет и долг.
• Доля времени на баги vs. новую функциональность — рост доли «тушения пожаров» — тревожный сигнал.
• Onboarding time нового разработчика до первого значимого коммита.
• Частота инцидентов, привязанная к конкретному модулю, а не к системе в целом.
Практические шаги
1. Ведите реестр долга — доска или лейбл в бэклоге для каждого осознанного «сделаем по-быстрому», с оценкой цены возврата.
2. Договоритесь о «бюджете» на долг заранее — например, 15–20% каждого спринта на технические задачи.
3. Привязывайте возврат долга к бизнес-событиям: «рефакторим модуль оплаты перед подключением нового провайдера» звучит убедительнее, чем «давно пора переписать».
4. Оценивайте технические задачи в тех же координатах, что и фичи — в ожидаемой экономии времени за 3–6 месяцев.
5. Не продавайте рефакторинг как разовую акцию — системный процент времени держится дольше, чем героический «спринт чистоты».
Вывод
По сути, весь фокус в том, чтобы перестать воевать — «разработчики против бизнеса» — и начать говорить на одном языке: скорости, денег, рисков. Задача инженеров тут не в том, чтобы убедить кого-то, что долг это плохо — все и так это подозревают. Задача — дать конкретные цифры, на которые можно опереться при принятии решения. А задача менеджмента — заранее оставить пространство для возврата долга, а не героически тушить пожар в тот самый момент, когда «доделаем потом» наконец наступает. Потому что оно всегда наступает.
Share
