Can We Please Stop Talking About Tech Debt? • Emily Rosengren • GOTO 2023

Противоречивый доклад с концеренции goto, в котором Emily рассказывает про техдолг и предлагает не называть технические задачи так:) Аргументация состоит в том, что со времен Уорда Канингема, придумавшего эту метафору, наша индустрия поменялась. Саму концепцию Уорда Канингема хорошо описал Мартин Фаулер в своей статье "Technical debt": Software systems are prone to the build up of cruft - deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further. Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt. Эмили апелирует к следующим изменениям:

• переход от проектной работе к продуктово-ориентированным командам - мы инвестировали в изменение подходов к организации команд для создания софта в другом формате
• распространение cloud-native distributed systems - область, которую можно отнести к долгу увеличилась
• появился целый зоопарк технологий (с 1992 года, когда концепция техдолга появилась)

Дальше Эмили подводит к мысли, что There is bad software and better software, but no such thing as "best" or "the right" implementation и отсюда появляется мысль, что Software and context around it is continually changing - the best tradeoffs come from current context

Дальше автор доклада предлагает не навешивать label техдолг на какие-то технические задачи, а влиять целиком на улучшение продукта и она предлагает такой алгоритм для того, чтобы делать это успешно:

• Do the work when it matters
• Explain the "why"
• Understand the product roadmap and care about it too

Дальше она разбирает стандартный тезис инженеров вида "I can't get my tech debt prioritized" и предлагает переформулировать это в утверждение другого вида "I can get my timely. prroduct-strategy-relevant improvement recommendations prioritized":)

P.S. В принципе, мысли у автора хорошие, но кажется, что это просто изменение названия, но не концептуальное изменение подхода. Мне гораздо больше нравится подход Джона Остерхута со стратегическим программированием, что он описывал в книге "A philosophy of software design" (вот тут есть краткое описание книги, которую мы разбирали в клубе Code of Architecture). Плюс я думаю, что надо делать технические инвестиции up-front с точки зрения внедрения инженерных практик в новые проекты, а не ждать накопления долга и выплаты процентов.

#Engineering #Architecture #Processes #Management #Leadership