Comments 24
Энтропийная модель проектных команд с привлечением законов термодинамики — это хорошо, но по сравнению с материей у человеков есть одно ключевое отличие: разум, подобно тепловому насосу, способен понижать энтропию в конечной области Вселенной, естественно, за счет увеличения за ее пределами.
Поскольку нас прежде всего интересует энтропия кодовой базы, то бабка говорит надвое — добавление новых людей в команду может как ее увеличить, так и уменьшить. Все зависит от вышеуказанной способности этих людей вносить упорядочивающую составляющую в процесс разработки.
К командной работе можно привести и электротехническую аналогию — как повлияет на отдаваемую батареей элементов мощность добавление к батарее еще одного элемента? Ответ в реальности троякий, и зависит от внутреннего сопротивления добавляемого элемента, его ЭДС и сопротивления нагрузки. Так и в команде.
Поскольку нас прежде всего интересует энтропия кодовой базы, то бабка говорит надвое — добавление новых людей в команду может как ее увеличить, так и уменьшить. Все зависит от вышеуказанной способности этих людей вносить упорядочивающую составляющую в процесс разработки.
К командной работе можно привести и электротехническую аналогию — как повлияет на отдаваемую батареей элементов мощность добавление к батарее еще одного элемента? Ответ в реальности троякий, и зависит от внутреннего сопротивления добавляемого элемента, его ЭДС и сопротивления нагрузки. Так и в команде.
Поскольку нас прежде всего интересует энтропия кодовой базы, то бабка говорит надвое — добавление новых людей в команду может как ее увеличить, так и уменьшить. Все зависит от вышеуказанной способности этих людей вносить упорядочивающую составляющую в процесс разработки.
Конечно вы правы, если пытаться рассмотреть какую-то конкретную команду разработки и конкретный проект.
Но я полностью согласен с автором, что если мы берем среднего разработчика и команда у нас состоит из средних или скажем одинаково хороших разработчиков и мы добавляем туда еще одного такого же условно хорошего разработчика, то не стоит ожидать что система начнет меняться и энтропия начнет исчезать. Она таки начнет возрастать. В этом смысле, если говорить про чистую разработку в отрыве от других подразделений, то таки сократив число разработчиков можно в среднем добиться падения роста энтропии.
ЗЫ: В этом смысле, мода на микросервисы, это именно о том, чтобы в кодовой базе чего-то определенного копалось меньше разработчиков. Таким образом мы достигаем снижения энтропии разбив монолит и раздробив большую команду на более мелкие.
Комплектация проектных команд — не гауссовый процесс — она является результатом добавления в систему информации (осознанного решения [толкового] менеджера)
Ваш же пример со средним разрабом будет справедлив в случае, если количество информации, привносимой в команду менеджером, строго равно нулю.
Положим, что в большинстве проектных команд это все-таки не так. Следовательно, если цель — уменьшение энтропии, то добавляемый в батарею элемент будет более качественным (то есть иметь лучшее отношение E/ri) — иными словами, разраб будет более квалифицированным и дорогим, чем средняя смесь в команде.
Обратная задача — удешевить выход проекта за счет допустимого роста технического долга в самом конце (и удорожания пост-продакшен поддержки в будущем [но об этом думать будет уже менеджер команды сопровождения]) — решается добавлением в смесь менее качественных и более дешевых разрабов
Ваш же пример со средним разрабом будет справедлив в случае, если количество информации, привносимой в команду менеджером, строго равно нулю.
Положим, что в большинстве проектных команд это все-таки не так. Следовательно, если цель — уменьшение энтропии, то добавляемый в батарею элемент будет более качественным (то есть иметь лучшее отношение E/ri) — иными словами, разраб будет более квалифицированным и дорогим, чем средняя смесь в команде.
Обратная задача — удешевить выход проекта за счет допустимого роста технического долга в самом конце (и удорожания пост-продакшен поддержки в будущем [но об этом думать будет уже менеджер команды сопровождения]) — решается добавлением в смесь менее качественных и более дешевых разрабов
Модель потерь в микросервис-архитертуре — это переходные сопротивления и помехи на контактах множества межблочных соединений. Самы блочки при этом выглядят опрятно и аккуратно. Залиты лаком — не грех заказчику показать, или на выставке похвастаться.
В полевых же условиях очень многое зависит от уровня деления и качества разъемов. Чтобы микросервисы при интенсивной замене блоков продолжали надежно работать — разъемы должны быть с военной приемкой, и сплошь золоченые.
Вы понимаете аналогию — стоимость поддержки когерентности межсервисных соглашений при их большом количестве и интенсивной модернизации сервисов растет квадратично!
Так что для сложных систем и/или динамичных стартапов опять приходит бабка и говорит надвое, кашляя и ругаясь на очередной технологический хайп
В полевых же условиях очень многое зависит от уровня деления и качества разъемов. Чтобы микросервисы при интенсивной замене блоков продолжали надежно работать — разъемы должны быть с военной приемкой, и сплошь золоченые.
Вы понимаете аналогию — стоимость поддержки когерентности межсервисных соглашений при их большом количестве и интенсивной модернизации сервисов растет квадратично!
Так что для сложных систем и/или динамичных стартапов опять приходит бабка и говорит надвое, кашляя и ругаясь на очередной технологический хайп
Понимаю и мне аналогия кажется очень уместной и наглядной.
Именно поэтому переход на микросервисы далеко не всегда являются улучшением. Но в то же время если говорить про энтропию, энтропия кодовой базы таки должна снижаться. просто она повысится теперь где-то в другом месте, на стыке микросервисов :-)
Именно поэтому переход на микросервисы далеко не всегда являются улучшением. Но в то же время если говорить про энтропию, энтропия кодовой базы таки должна снижаться. просто она повысится теперь где-то в другом месте, на стыке микросервисов :-)
Да, в определенном смысле, в этом даже есть резон — в отличие от блоков, структура которых сложная и многообразная, соединения — просты и подобны. Это значит, что метод поддержания низкой энтропии всех соединений системы может быть по сути один, и за счет этого можно достичь определенного снижения функции затрат при фиксированной функциональной сложности и общей энтропии системы.
Есть, правда, еще один класс проблем мультисервисов — конечная скорость распространения межмодульной информации — здесь полная аналогия с понятием «длинная линия» в электронике, вследствие чего когерентные межмодульные операции становятся либо очень сложны, либо невозможны. И это — тоже вытеснение сложности в другое измерение (в данном случае — из технической в бизнес-плоскость).
Короче, все эти усилия — суть домкраты, трансформаторы, полиспасты и тому подобные приборы с конечным КПД — результат преобразований энергии в информацию о том, как обыграть Природу в том или ином частном случае :)
Есть, правда, еще один класс проблем мультисервисов — конечная скорость распространения межмодульной информации — здесь полная аналогия с понятием «длинная линия» в электронике, вследствие чего когерентные межмодульные операции становятся либо очень сложны, либо невозможны. И это — тоже вытеснение сложности в другое измерение (в данном случае — из технической в бизнес-плоскость).
Короче, все эти усилия — суть домкраты, трансформаторы, полиспасты и тому подобные приборы с конечным КПД — результат преобразований энергии в информацию о том, как обыграть Природу в том или ином частном случае :)
В одной из книг о микросервисах была целая глава о том, когда не нужно их применять. Одним из пунктов было неумение/незнание/непонимание компанией технологий контейнеризации и оркестрации: без них работа с микросервисами быстро превратится в ад.
Интересная аналогия. В принципе, многие приемы управления разработкой в команде при должном применении делают замену или добавление новых разработчиков таким же простым и предсказуемым процессом, как добавление нового элемента к батарее.
Технический долг — метафора. А статья предлагает метафоры к метафоре.
Кто нибудь объяснит о чем все таки речь?
Если это действительно долг, то почему его не взыскивают через суд?
Если это просто не идеальный код, то где доказательства что идеальный код существует?
Словом как количественно оценить этот долг если он объективно существует как явление, а не как субъективное ощущение?
Кто нибудь объяснит о чем все таки речь?
Если это действительно долг, то почему его не взыскивают через суд?
Если это просто не идеальный код, то где доказательства что идеальный код существует?
Словом как количественно оценить этот долг если он объективно существует как явление, а не как субъективное ощущение?
Если это действительно долг, то почему его не взыскивают через суд?зачем обязательно через суд? его и так жизнь взыскивает. с пенями.
Гляньте то расширение, которое разработали авторы этой статьи. Там описаны вполне измеримые количественные критерии запутанного и сложного в сопровождении кода:
Полюбопытствуйте
- длина функций
- цикломатическая сложность
- метрика сложности Холстэда
- количество аргументов функций
- глубина вложенности
- насыщенность кода комментариями
Полюбопытствуйте
Ну, полюбопытствовал. Всё перечисленное там — это не метрики технического долга, а метрики сложности кода. Технический долг же — это не вся, а лишь избыточная часть сложности кода.
Кроме избыточной сложности в программе есть ещё необходимая сложность, которая определяется сложностью самой задачи (и её предметной области), для решения которой и создана программа. И которую (сложность) невозможно определить a priori. Поэтому сама идея измерения технического долга сталкивается в реальности с неустранимой систематической ошибкой такого измерения.
Помимо этого, идея померить сложность несколькими метриками неизбежно приведет к тому, что начнет действовать закон Гудхарта: когда показатель становится целевым в политике управления, то эмпирическая закономерность, на основе которой можно этот показатель использовать для управлния, перестает выполняться.
В нашем случае, если менеджмент попытается контролировать подобным способом технический долг, наемные разработчики и их команды научатся, грубо говоря, обманывать систему оценки технического долга, прятать избыточную сложность кода способами, не контролируемыми по отслеживаемым менеджментом показателям — просто чтобы не портить себе формальную оценку от которой будет зависеть их доход. В частности, перечисленные в статье по ссылке показатели — они вполне подвержены такому обману.
Например, формально уменьшить число строк в функции вполне возможно за счет механического разбиения её на дочерние процедуры, с передачей общего (и изменяемого внутри дочерних процедур) состояния родительской функции между ними через передаваемые по ссылке параметры, глобальные переменные и т.д., чтобы не уменьшать реальную сложность программы. Число ветвей исполнения можно аналогичным образом уменьшить формально, перенеся их реализацию в дочерние процедуры, но принимая решения об используемых ветвях в родительской функции и передавая все принятые решения с помощью единственного параметра-набора флагов; число аргументов можно формально уменьшить, передавая вместо многих аргументов один содержащий их объект; требование о количестве комментариев можно формально соблюдать, комментируя очевидные вещи: я вряд ли когда-нибудь забуду забавный комментарий «Handy 1»(«удобная единица») к команде загрузки 1 в регистр процессора в написанном на ассемблере модуле IBM VM/SP — для которого фирменный стандарт, по-видимому, требовал комментировать каждый оператор.
И так далее: для каждой метрики «технического долга» найдется способ её формального соблюдения без фактического сокращения сложности — как писал Эд Пост в своей очень старой и хорошо известной статье «закоренелый настоящий программист может написать фортрановскую программу на любом языке».
Кроме избыточной сложности в программе есть ещё необходимая сложность, которая определяется сложностью самой задачи (и её предметной области), для решения которой и создана программа. И которую (сложность) невозможно определить a priori. Поэтому сама идея измерения технического долга сталкивается в реальности с неустранимой систематической ошибкой такого измерения.
Помимо этого, идея померить сложность несколькими метриками неизбежно приведет к тому, что начнет действовать закон Гудхарта: когда показатель становится целевым в политике управления, то эмпирическая закономерность, на основе которой можно этот показатель использовать для управлния, перестает выполняться.
В нашем случае, если менеджмент попытается контролировать подобным способом технический долг, наемные разработчики и их команды научатся, грубо говоря, обманывать систему оценки технического долга, прятать избыточную сложность кода способами, не контролируемыми по отслеживаемым менеджментом показателям — просто чтобы не портить себе формальную оценку от которой будет зависеть их доход. В частности, перечисленные в статье по ссылке показатели — они вполне подвержены такому обману.
Например, формально уменьшить число строк в функции вполне возможно за счет механического разбиения её на дочерние процедуры, с передачей общего (и изменяемого внутри дочерних процедур) состояния родительской функции между ними через передаваемые по ссылке параметры, глобальные переменные и т.д., чтобы не уменьшать реальную сложность программы. Число ветвей исполнения можно аналогичным образом уменьшить формально, перенеся их реализацию в дочерние процедуры, но принимая решения об используемых ветвях в родительской функции и передавая все принятые решения с помощью единственного параметра-набора флагов; число аргументов можно формально уменьшить, передавая вместо многих аргументов один содержащий их объект; требование о количестве комментариев можно формально соблюдать, комментируя очевидные вещи: я вряд ли когда-нибудь забуду забавный комментарий «Handy 1»(«удобная единица») к команде загрузки 1 в регистр процессора в написанном на ассемблере модуле IBM VM/SP — для которого фирменный стандарт, по-видимому, требовал комментировать каждый оператор.
И так далее: для каждой метрики «технического долга» найдется способ её формального соблюдения без фактического сокращения сложности — как писал Эд Пост в своей очень старой и хорошо известной статье «закоренелый настоящий программист может написать фортрановскую программу на любом языке».
Это статья из корпоративного блога компании, которая занимается разработкой решений для отслеживания и устранения технического долга в коде с помощью IDE. Так что, думаю, она обращена прежде всего не к менеджменту, а к разработчикам, то есть людям, работающим с кодом, небезразличным к своей работе, желающим ее улучшить. Про менеджмент там скорее посыл в том, что выплачивать технический долг так же важно, как и выкатывать новые фичи, и нельзя экономить на первом за счет второго — это может плохо кончиться. В остальном совершенно с вами согласен: если разработчикам наплевать на то, как они пишут код, как их работа влияет на других в команде и на фирму в целом, и единственная их цель — выполнить спущенные сверху формальные показатели, то да, никакие метрики, KPI и т.п. не заставят их делать свою работу хорошо — обойдут, обманут, подкрутят. Это уже не команда, слаженно работающая на достижение общей цели. Но это уже совсем другая проблема, и такая организация, на мой взгляд, глубоко больна и находится на пути к краху.
Ну все к тому и пришло.
«Технический долг» — эвфемизм фразы «вы виноваты».
Т.е. виноваты простыне кодеры, поскольку превысили цикломатичность и все такое.
Причем граница для всех критериев «долга» выбирается эмпирически, как пишут сами авторы этого набора критериев.
Хочешь усилить чувство вины молодых кодеров — опусти границу цикломатичности.
При этом избегается тема получения единой оценки долга, т.е. агрегирования оценок по всем критериям и получения единственного числа, а главное определение справедливой границы.
Отличный инструмент психологического давления.
«Технический долг» — эвфемизм фразы «вы виноваты».
Т.е. виноваты простыне кодеры, поскольку превысили цикломатичность и все такое.
Причем граница для всех критериев «долга» выбирается эмпирически, как пишут сами авторы этого набора критериев.
Хочешь усилить чувство вины молодых кодеров — опусти границу цикломатичности.
При этом избегается тема получения единой оценки долга, т.е. агрегирования оценок по всем критериям и получения единственного числа, а главное определение справедливой границы.
Отличный инструмент психологического давления.
Если без лишних сложностей, давайте думать о нашей кодовой базе как о замкнутой системе. Отбросим внешние зависимости и всё, что живет за пределами нашей кодовой базы. В этих условиях — неизменное количество разработчиков, разработка фич в стабильно высоком темпе — количество энтропии (мера беспорядка и случайности в системе) в нашей кодовой базе остается постоянной.
Из неправильного предположения вытекает неправильное следствие — в итоге, так или иначе в техническом долге виноваты только разработчики, пусть это можно списать на сущность человеческой природы.
На практике, кодовая база это не закрытая система. Она катастрофически часто претерпает проблемы со стороны заказчика (аутсорс) или бизнеса (продуктовая разработка). И обычно все проблемы бизнеса в духе кривых бизнес-процессов или "сделай как-то так, там же все понятно" в первую очередь отображаются в ней, потому что плохо продуманные бизнес-процессы как-то людьми залепить можно, а с кодом так не сработает.
Об этом в статье есть, и не один раз:
Вы ведь статью прочитали полностью?
- общее убеждение бизнеса, что технический долг — проблема только команд разработчиков
- недооценивание всей серьезности технического долга и его влияния на возможности роста бизнеса
- постоянное давление со стороны рынка («делай быстро или конкуренты обгонят»)
- ложно понимаемая дилемма «новые фичи или рефакторинг», чаще всего решаемая в пользу первого варианта
Вы ведь статью прочитали полностью?
Об этом в статье есть, и не один раз:
Эти утверждения же не опровергают ложного вывода статьи в том, что "источник технического долга — разработчики". Разумеется, проблемы IT отдела (как и любого другого) в итоге будут проблемами бизнеса, но в том числе важно понимать, что очень часто именно бизнес-решения порождают технический долг, а не "неидеальность" разработчиков.
Я могу переформулировать это как "очень часто технический долг не возникает сам по себе, а бизнес намеренно увеличивает технический долг зная или игнорируя риски с ним связанные, дабы получить выгоду для себя".
Непосредственный источник технического долга в кодовой базе — это именно разработчики, потому что именно они работают с кодом и вносят в него изменения, так что вывод отнюдь не ложный. Именно разработчик решает реализовать бизнес-требования через костыль, и именно он вносит этот костыль в код и берет тем самым на себя ответственность и за этот костыль, и за его будущую судьбу, и за рост долга, и за его влияние на всех прочих в команде, и даже за влияние этого костыля на бизнес в целом. Удобно все свалить на злых менеджеров, но ведь и менеджеры со своей стороны не всегда понимают, что делают разработчики, к каким последствиям это может привести, и главное — в конечном счете это не они пишут код с костылями.
Именно разработчик решает реализовать бизнес-требования через костыль, и именно он вносит этот костыль в код и берет тем самым на себя ответственность и за этот костыль
У вас сроки реализации тоже разработчик сам себе ставит? Я обычно видел ситуации, когда есть срок, к которому нужно реализовать фичи, к которому ее реализовать нормально нельзя и происходит стандартный диалог на тему "ну мы же потом перепишем — конечно", а потом чуда не происходит.
А еще это мы не затрагивает ситуацию, когда какой-то топ-менеджер по 6 раз кардинально меняет требования к задаче в течении времени ее реализации. И каждый раз давит на разработчиков с тем, что бы ее реализовали быстрее. В итоге код будет просто отвратительный и тоже разработчики будут виноваты?
Странный разработчики, если поддаются на давление.
Я, например, никогда не буду писать код, который мне совсем уж не нравится (например, без проверки ошибок или без должной декомпозиции).
Я могу оставить костыль, только если мне будет лень писать правильно, например, я уже устал от какой-то задачи и сам хочу быстрее её завершить. Но это моё решение, а не какого-то менеджера.
Не представляю, чем они могут оказывать давление. Если репутационно, типа «смотри, Вася фигачит в 3 раза быстрее» — то я спокойно отвечу «ну и фигня у него получается, так что пофиг», если же через премии, то я посчитаю это несправедливым и скажу такому работодателю «давай, до свидания», хотя таких прецедентов не было. Благо, сейчас рынок на стороне работника.
Я, например, никогда не буду писать код, который мне совсем уж не нравится (например, без проверки ошибок или без должной декомпозиции).
Я могу оставить костыль, только если мне будет лень писать правильно, например, я уже устал от какой-то задачи и сам хочу быстрее её завершить. Но это моё решение, а не какого-то менеджера.
Не представляю, чем они могут оказывать давление. Если репутационно, типа «смотри, Вася фигачит в 3 раза быстрее» — то я спокойно отвечу «ну и фигня у него получается, так что пофиг», если же через премии, то я посчитаю это несправедливым и скажу такому работодателю «давай, до свидания», хотя таких прецедентов не было. Благо, сейчас рынок на стороне работника.
Неадекватность менеджмента, не встречающая отпора от исполнителей. Типичная ситуация, хорошо знакомая всем, наболевшая. Проиграют в итоге и те, и другие.
Давайте обратимся к различным областям науки за некоторыми подсказками, потому что законы термодинамики могут подарить нам ключевые идеи для понимания того, почему технический долг неизбежен.
давайте, но только к тем, которые изучают открытые развивающиеся системы с обратной связью
Sign up to leave a comment.
Простые причины неизбежности технического долга