Технический долг - бьем на части и ликвидируем.

Бери да помни! Не штука занять, штука отдать.

В последнее время очень часто обсуждается тема технического долга. Делается много докладов, пишется много постов, рисуется много графиков и тд, и тп.

Но чем больше я об этом думаю, тем ближе мне высказывание Романа Ивлева "почитал интернеты на предмет борьбы с техническим долгом. Вывод: лучший способ борьбы - не будь должен вообще. С начала и до конца".

Но такой идеальный вариант возможен только в случае, когда вы начинаете с самого начала, и пока вы и только вы отвечаете за принятие решения. В этом случае, у вас есть возможность и стимул сохранять свой положительный баланс в неприкосновенности, не допуская туда кредиторов :)

Как только вы дали слабину и приняли заведомо спорное (или компромиссное) решение, вы должны отдавать себе отчет - ваш баланс стал отрицательным. И если в самое ближайшее время вы его не выправите, дальше будет все сложнее и сложнее выделить время, ресурсы, деньги (нужное подчеркнуть) на то, чтобы исправить ситуацию.
Дальше хуже: теория разбитых окон проявится во всей своей красе.

А если вы попали в проект, история которого насчитывает больше 2-3 лет, то вы без вариантов попадаете в ситуацию, когда разбитых окон уже полно. Что еще прикольней, разбиты они не вами, а задолго до вас.

Для того, чтобы яснее представлять себе как бороться с этим злом, предлагаю рассматривать достаточно общее понятие технического долга как совокупность разных долгов. Так, на мой взгляд, проще - бить точечно по конкретным проблемам.

Давайте вспомним, что мы обычно понимаем под техническим долгом. Согласно классическому определению, данному Уордом Каннигемом (Ward Cunningham), технический долг - это разница между идеальным техническим решением и тем решением, которое принимается сейчас.

Для нас, людей занимающихся разработкой программных продуктов, техническим решением является и то как мы будем делать (архитектурно), и то каким языком программирования будем пользоваться, и то какие практики будут использоваться, и то как это будет тестироваться, и тд и тп. Соответственно и долги будут свои в каждой из этих областей.

Получается, что мы может говорить о следующих видах долга:
- долг реализации
- технологический
- процессный
- долг компетенции

IT, по мотивам cartmendum

Долг реализации: сюда можно отнести то, что обычно и понимают под техническим долгом, на мой взгляд узко смотря на эту проблему. Приобрести этот долг можно и приняв неправильные архитектурные решения (вот тут аккуратно, очень скользкий момент), и добавив "костыли" в коде, и упростив процесс тестирования оставив там только "успешные" сценарии. Сюда же добавим и невозможность рефакторить исходный код, которая вызвана отсутствием тестов, что зацикливает эту проблему и вводит в клинч, когда все больше времени требуется на добавление новых фичей, потому что постоянно умирают старые. Очень ярко это отражено в твите (18+), читайте комменты - это просто песня. Я прослезился. Или наоборот "рефакторится" все направо и налево, а проверяют все это тестировщики ручками.

Долг технологический приобретается через отказ от применения новшеств в языках, фреймворках, инструментах. У меня на глазах пример использования С++, когда часто можно наблюдать осторожность (мягко говоря) во внедрении С++11, когда отказываются от использования boost'a, когда продолжают писать свои мега-крутые "велосипеды" игнорируя open-source библиотеки. Все это приводит к замедлению разработки, снижению качества и даже к снижению мотивации у людей, потому что они используют "несвежие" инструменты.
Очень пересекается с Innovation Debt.

В кабалу процессного долга можно попасть отказываясь или затягивая принятие решений по применению Continuous Integration, XP-практик. Отсутствие веры, желания, понимания важности этого всего приводит к тому, что эти задачи, как правило с нижайшим приоритетом, накапливаются в списке общих задач. Потому что у нас всегда есть суперсрочные и суперважные для продукта задачи. И как следствие, только для того чтобы просто понять, что свежесобранный сетап не работает, приходится тратить от 10 мин до N часов (зависит от навороченности продукта).

Долг компетенции возникает из-за узкоспециализированной разработки, когда в команде есть человек(и) с уникальными знаниями. Это усугубляется отсутствием обмена знаниями или, хотя бы, обмена возникающими проблемами и принятым по ним решениям. Такое можно наблюдать в масштабе и целой компании, и даже маленькой команды. В итоге, принимаются решения заведомо неверные, которые у человека разбирающегося в вопросе вызывают дикое удивление. И это нас возвращает к долгу реализации. А если спец уходит, то вообще возникает вакуум и код, которые он суппортил, превращается в магический лабиринт из языковых инструкций, которые реализуют "нечто". К нему стараются не прикасаться без крайней необходимости, при первой же возможности к нему применяется паттерн "invented not here" и он помечается черной меткой под названием "переписать".

Обо все этом мы сможем с вами поговорить на конференции BitByte, 25 апреля в Питере. Приходите, буду рад пообщаться. В том числе и про способы ликвидации долга. Не дайте импотеке управлять вами! :)

Мой отчет с выступления. Там же можно найти много полезных линков на эту тему.

Пишите комментарии здесь, может я излишне пессимистичен или все усложняю :)

Слайды с аналогичного выступления на IT Global Meetup SPb

ITGM#4 Технический долг 2.0 from Maxim Shulga

Список материалов, которые могут помочь разобраться с этим вопросом подробнее:

Материалы с сайта Уорда Канингема:
Technical Debt
Видео с объяснением что такое тех долг от Уорда

Попытка посчитать сколько может стоить долг

Мартин Фаулер про техдолг

Интересная статья Сергея Теплякова

Про долг компетенции

Выступление Бориса Вольфсона на тему технического долга, очень рекомендую

Видео доклада про технический долг с AgileDays'14

Еще интересно про тех.долг

Про неправильные метафоры технического долга.

"Не тратьте время на отслеживание технического долга" - интересные мысли.

Сборник статей по тех.долгу

"Технический долг как избыточный вес"

"Technical Debt: The Man, the Metaphor, the Message":
"The “debt” is the missing parts of our understanding of the problem and the necessary solution; not the quality of the code we write. Whatever code we write, we’re expected to write as well as we can. Always."

Tech debt is not a burden, it's a strategic lever for success

Достаточно подробно с примерами, классификацией подтипов и тем, что со всем этим "добром" делать.