Про техдолг (#полуинженерное)
Я у мамы инженер, добавил новый тег. Много стало этого слова вокруг в какой-то момент, решил немного порассуждать.
Этот термин, а на самом деле не совсем термин, а скорее метафора, была первоначально придумана Уордом Каннингемом, и с тех пор широко должна была использоваться для описания ситуации, когда имеет место выбор между недорогим и быстрым решением вместо дорогого, но лучшего. Это создает «долг», который со временем может накапливать «проценты», что значительно усложняет внесение изменений в систему, усложнит и удорожит ее поддержку. Но под доброй традиции что-то пошло не так.
NB. При этом техдолг есть всегда - проблемы проектирования неизбежны, если вы работаете над частичным пониманием проблемы или над сферическим куском функционала в вакууме (привет, системное мышление), боолее того - технический долг — естественная и неизбежная часть гибкой разработки (привет, моя любовь к гибким методологиям).
В последнее время техдолг стал универсальным термин для обозначения не "долга", а «бардака», который неизбежно нарастает при содействии нечетких требований, недальновидного планирования, плохой аналитики и дизайна, борьбы за получение быстрого результата, недальновидных проектных решений и хренового кода. В оригинале Уорд не предполагал, что хуманы будут осознанно писать плохой код с намерением исправить его позже : «Я никогда не топлю за плохое написание кода».
Но хуманы приспособились использовать эту метафору, чтобы, например, отмазаться от плохих проектных решений. Современная проектная среда поощряет создание быстрых, но кривых решений, при этом разработкичи часто пребывают в уверенности, то что бизнес будет готов инвестировать в исправление косяков позже (нет!). Спустя время команды утверждают, что код - отстой, потому что было вложено слишком мало времени и сил в хороший дизайн и лучшие технические практики. Но реальность такова, что получить бюджет времени и денег на переписывание существующих функций крайне сложно. Более того, у бизнеса всегда есть один резонный вопрос - какого хрена не сделали сразу нормально, а теперь вынуждаете меня снова оплачивать те же самые работы. И это гарантировано приводит к конфронтациям между сторонами. Отсюда вечный спор - больше фич, но быстрее vs меньше фич, но медленнее. Мир слишком быстр, чтобы ждать, пока вы сделаете правильно и хорошо:)
А чо делать? Смириться? Только в том случае, когда мы понимаем, что долг можно будет не выплачивать. Есть куча случаев, когда овнокод и сложная база кода - это именно то, что подходит для предоставления функции клиенту с наименьшими затратами для бизнеса. То, что код выглядит, как хрень и местами также работает, часто не является поводом для дополнительных инвестиций в разработку. Бизнес стойко будет переносить это все, если это будет выгодно. Почему? Потому что коммерческие проблемы почти всегда лучше сформулированы и сформулированы в терминах, понятных и понятных остальной части бизнеса. А не эти ваши паттерны и луковые архитектуры.
Поэтому верный путь решения этой задачи - развивать умение доносить свои аргументы, научившись использовать язык денег. Можно ведь подсчитать сколько обойдутся последствия хреновой разработки? - это как минимум дополнительные затраты на привлечение людей, большая вероятность возникновения инцидентов и замедление разработки. Но торговаться надо не ПОСЛЕ, а ДО. Т.е. вкладывать чуть больше времени на аналитику, чуть больше времени на дизайн, чуть лучше прорабатывать задачи и т.д. Как только возникнет финансовая заинтересованность с той стороны - бодания перейдут в переговоры. Разработчики по хорошему должны научиться выражать свои аргументы в терминах, которые помогут выиграть спор, а не рассчитывать на победу с помощью предъявления технического долга в будущем. Иначе в моменте наступит технологический дефолт - размер долга станет таким, что отдать его будет невозможно. Sic!
Вот такое вот уже субботнее получилось.
Писать полуинженерные тексты сильно сложнее, чем тексты про управление. Не забывайте свои корни.
Я у мамы инженер, добавил новый тег. Много стало этого слова вокруг в какой-то момент, решил немного порассуждать.
Этот термин, а на самом деле не совсем термин, а скорее метафора, была первоначально придумана Уордом Каннингемом, и с тех пор широко должна была использоваться для описания ситуации, когда имеет место выбор между недорогим и быстрым решением вместо дорогого, но лучшего. Это создает «долг», который со временем может накапливать «проценты», что значительно усложняет внесение изменений в систему, усложнит и удорожит ее поддержку. Но под доброй традиции что-то пошло не так.
NB. При этом техдолг есть всегда - проблемы проектирования неизбежны, если вы работаете над частичным пониманием проблемы или над сферическим куском функционала в вакууме (привет, системное мышление), боолее того - технический долг — естественная и неизбежная часть гибкой разработки (привет, моя любовь к гибким методологиям).
В последнее время техдолг стал универсальным термин для обозначения не "долга", а «бардака», который неизбежно нарастает при содействии нечетких требований, недальновидного планирования, плохой аналитики и дизайна, борьбы за получение быстрого результата, недальновидных проектных решений и хренового кода. В оригинале Уорд не предполагал, что хуманы будут осознанно писать плохой код с намерением исправить его позже : «Я никогда не топлю за плохое написание кода».
Но хуманы приспособились использовать эту метафору, чтобы, например, отмазаться от плохих проектных решений. Современная проектная среда поощряет создание быстрых, но кривых решений, при этом разработкичи часто пребывают в уверенности, то что бизнес будет готов инвестировать в исправление косяков позже (нет!). Спустя время команды утверждают, что код - отстой, потому что было вложено слишком мало времени и сил в хороший дизайн и лучшие технические практики. Но реальность такова, что получить бюджет времени и денег на переписывание существующих функций крайне сложно. Более того, у бизнеса всегда есть один резонный вопрос - какого хрена не сделали сразу нормально, а теперь вынуждаете меня снова оплачивать те же самые работы. И это гарантировано приводит к конфронтациям между сторонами. Отсюда вечный спор - больше фич, но быстрее vs меньше фич, но медленнее. Мир слишком быстр, чтобы ждать, пока вы сделаете правильно и хорошо:)
А чо делать? Смириться? Только в том случае, когда мы понимаем, что долг можно будет не выплачивать. Есть куча случаев, когда овнокод и сложная база кода - это именно то, что подходит для предоставления функции клиенту с наименьшими затратами для бизнеса. То, что код выглядит, как хрень и местами также работает, часто не является поводом для дополнительных инвестиций в разработку. Бизнес стойко будет переносить это все, если это будет выгодно. Почему? Потому что коммерческие проблемы почти всегда лучше сформулированы и сформулированы в терминах, понятных и понятных остальной части бизнеса. А не эти ваши паттерны и луковые архитектуры.
Поэтому верный путь решения этой задачи - развивать умение доносить свои аргументы, научившись использовать язык денег. Можно ведь подсчитать сколько обойдутся последствия хреновой разработки? - это как минимум дополнительные затраты на привлечение людей, большая вероятность возникновения инцидентов и замедление разработки. Но торговаться надо не ПОСЛЕ, а ДО. Т.е. вкладывать чуть больше времени на аналитику, чуть больше времени на дизайн, чуть лучше прорабатывать задачи и т.д. Как только возникнет финансовая заинтересованность с той стороны - бодания перейдут в переговоры. Разработчики по хорошему должны научиться выражать свои аргументы в терминах, которые помогут выиграть спор, а не рассчитывать на победу с помощью предъявления технического долга в будущем. Иначе в моменте наступит технологический дефолт - размер долга станет таким, что отдать его будет невозможно. Sic!
Вот такое вот уже субботнее получилось.
Писать полуинженерные тексты сильно сложнее, чем тексты про управление. Не забывайте свои корни.