💬 Одной из проблем при найме разработчиков является заблуждение о небольшом разбросе в их квалификации – ошибочное мнение, будто программисты не слишком отличаются друг от друга (с точки зрения производительности, качества кода и т. д.). Но исследования показывают, что верхний квартиль по уровню квалификации способен работать примерно вчетверо быстрее, чем нижний [Prechelt00]. Довольно большая разница, согласитесь. Кроме того, модель COCOMO, основанная на многолетних масштабных исследованиях, показывает, что уровень квалификации группы разработчиков – наиболее важный из всех факторов, влияющих на ее производительность [Boehm00]. Наконец, очень слабые программисты в среднем создают код худшего качества (с плохим дизайном) и с бо‌льшим количеством дефектов, что дополнительно тормозит всю систему.

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

Отложенный характер эффектов негативно влияет на способность системы к обучению и коррекции. Если результат или случайное следствие какого-либо действия проявляется с большой задержкой во времени, люди часто не видят (причинно-следственной) связи между ними, не понимают, что именно A повлияло на Б или, еще сложнее, что A повлияло на Б, а Б в ответ повлияло на А.

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

-- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева

Петли положительной или отрицательной обратной связи[9] и отложенные эффекты – тонкие моменты, которые делают динамику системы еще более сложной и менее понятной. К примеру, как программисты могут повысить свой уровень квалификации? Один из способов – учиться у высококвалифицированных специалистов и видеть много примеров отличного кода. Но компания, в которой работает много (очень дешевых) программистов с низкой квалификацией, производит мало образцов качественного кода, а также не привлекает и не может удержать крутых программистов, которые могли бы играть роль наставников. Те скорее найдут работу в другом месте.

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

Попробуйте… увидеть в системе петли положительной обратной связи.

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

-- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева

"Чтобы жизнь тебя устраивала, сначала устрой её. Иначе она устроит тебя не туда, куда тебя устраивает." — Стас Янковский

Невероятно меткое определение ключевой сути деятельности ИТ-специалиста. Как говорится, если Вы не занимаетесь архитектурой, то архитектура займется вами.

На каждом новом проекте в течении всей своей практики я начинал с того, что создавал себе (и другим) условия работы.

Вначале я научился писать высокоэффективный код. Это когда код качественный и пишется быстро.

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

Потом я понял, что нужно уметь формировать над командой защитный зонтик, чтоб они умели применять навыки в реальных условиях давления бизнеса. Бизнесу нужно быстро, команде нужно качественно, что означает тоже быстро, но завтра. Но бизнес это не всегда понимает. Найти баланс помогла книга "Extreme Programming Explained" 1st edition by Kent Beck.

Потом я понял, что крутой специалист может изменить все, кроме процессов. И именно безграмотно организованные процессы являются основной причиной утраты наиболее ценных специалистов, что обрело устойчивый термин "голосование ногами". И я начал изучать SDLC.

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

В принципе, я уже излагал эту историю здесь.

Чем отличается User Story от Task? Написать пост на эту тему меня потдолкнула недавно опубликованная ссылка на статью о техдолге в чате канала, а именно эти строки:

💬 "Doubtful developers may say, “But what if management deprioritizes or discards the technical debt subitems?”"

В целом статья неплохая, но есть нюанс. Как говорил человек, который создал роль Product Owner и Scrum-Master:

💬 "So I split the role in two, giving the Scrum Master the how and the Product Owner the what.
<...>
The Scrum Master and the team are responsible for how fast they're going and how much faster they can get. The Product Owner is accountable for translating the team's productivity into value."
—"Scrum: The Art of Doing Twice the Work in Half the Time" by Jeffrey Sutherland

Именно команда ответственна за скорость разработки. А скорость разработки напрямую зависит от внутреннего качества программы, т.е. за Software Design. Говоря архитектурным языком, команда отвечает за Quality Attribute Modifiability.

Product Owner описывает в User Story функциональный инкремент, в то время как команда декомпозирует его на Tasks, которые описывают системный инкремент.

Одна и та же функция может поддерживаться различными вариантами конструкций.
В качестве подпорки под дверь можно использовать конструкцию в виде камня, а можно и в виде книги.

И, наоборот, одна и та же конструкция может выполнять разные функции. Например, тот же камень можно использовать в качестве функции якоря, или орехи им колоть. Это т.н. дихотомия функции и конструкции.

Конструкция может совпадать с функцией, а может не совпадать. Как и Bounded Context (Solution Space) может совпадать с Subdomain (Problem Space), а может не совпадать.

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

Но вернемся к User Story. Поясню на примере. Камень сам по себе бесполезен для разжигания костра. Два камня бесполезны сами по себе. Но два камня во взаимодействии могут высекать искру. У них появилось новое, emergent свойство, т.е. они образовали систему. Система обладает свойствами, которыми её элементы по отдельности не обладают.

Так вот, Product Owner пишет "нужна искра". Это функциональный инкремент, добавляющий новую, видимую функциональность в систему, которую можно протестировать приёмочными тестами уровня компонентных или сквозных тестов.

Отдельно взятый камень протестировать на уровне компонента или системы нельзя, т.к. он сам по себе не обладает emergent свойствами. Они появятся только тогда, когда будут завершены все необходимые системные инкременты, которые образуют систему.

Product Owner не пишет в User Story "взять один камень, взять другой камень". Это пишет команда в Tasks, на которые декомпозируется User Story. Product Owner отвечат за функцию, а команда - за конструкцию.

Это нерушимое правило, нарушение которого приводит к накоплению техдолга и к деградации темпов разработки, что, в свою очередь, приводит к утрате экономической целесообразности итеративной разработки, поскольку внесение изменений становится дороже заблаговременного проектирования. На эту тему есть у меня хороший Long Read.

Команда не должна согласовывать с Product Owner системный инкремент. Вот что по этому поводу говорит Open Agile Architecture Standard:

💬 Fowler would strongly promote the view that code refactoring requires no justification; rather it is part of a developer's "day job". This does not mean that we have to take on a massive code restructuring exercise for a legacy codebase; on the contrary, there may be no reason whatsoever to restructure the code for a stable legacy project. However, that said, developers should refactor their code when the opportunity arises.
—"Open Agile Architecture™" by The Open Group, Chapter "6.5.1. Justifying Ongoing Investment in Architectural Refactoring"

Подробнее здесь.

Но тут есть еще один нюанс, о котором - в следующем посте.

Распределение функций между командой и Product Owner работает только тогда, когда достигается цель - поддержание постоянства скорости разработки по мере роста размеров системы. Иными словами, когда команда достаточно грамотна в Software Design. Именно об этом говорит принцип Agile Manifesto:

🔷 "Continuous attention to technical excellence and good design enhances agility."

Именно поэтому, на Snowbird Meeting присутствовал весь архитектурный бомонд того времени. Именно поэтому Agile был создан архитекторами.

Что произойдет, если команда недостаточно подготовлена по Software Design? Кодовая база будет загнивать, темпы разработки будут деградировать, команда утратит доверие со стороны Product Owner, и Product Owner начнет возводить защитные стены от команды, затягивая в свою зону ответственности все решения по системному инкременту. Иными словами, он начнет указывать команде не только то, "что" нужно сделать в User Story, но и "как" команда должна это реализовать. Т.е. возникнет ситуация, описанная в начале предыдущего поста.

Звучать это будет примерно так: "давайте пока поставим костыль, а потом исправим". Естественно, это "потом" никогда не наступит.

Команда тоже начнет возводить свою защитную стену, и начнет твердить, что все нужно сжечь и переписать. И возможно, команда даже уговорит Product Owner, и он выделит ресурсы, но через пару месяцев все снова сгниет. Потому что код или самоочищается, если команда знает Software Design, или загнивает.

Каждая сторона отгородилась от другой стороны непробиваемой стеной. Ключевая цель Agile утрачена. Agile больше не выполняет своих функций.

В моем списке литературы приводятся 5 книг, без которых остается мало шансов организовать эффективную разработку и завоевать доверие Product Owner.

Молодые специалисты часто думают, что они придут в компанию, и их научат работать. В подавляющем большинстве случаев их научат тому, как не нужно строить системы. Практически все известные мне крутые специалисты сформировались не благодаря условиям работы, а вопреки им.

Кто голосует за вариант 2, тот признает, что интеграционное событие должно находиться исключительно в инфраструктурном слое приложения. Соответственно, политика (Domain Event Hadler), создающая интеграционное событие, является адаптером, и тоже должна находиться в инфраструктурном слое. Соответственно, демонстрационное приложение от Microsoft содержало ошибку.

Сейчас я все больше осознаю свою цель.

Я вижу три проблемы, которые сложились в ИТ-отрасли:

1. Многие специалисты неудовлетворены условиями работы. По результатам опроса 2/3 неудовлетворены условиями работы, а каждый пятый регулярно испытывает желание уволиться. Недавно "проголосовал ногами" мой товарищ, достаточно сильный специалист.

2. Остутствие корреляции между реальным уровнем квалификации и уровнем зарплаты, в силу проблемы, известной в математике как "проблема лимонов и персиков". В силу этого, квалификация на рынке труда стремится к исчезновению, что отражается на снижении качества програмных продуктов.

3. Квалифицированные специалисты боятся выходить на коммерческий рынок, освобождая место для деятельности шарлатанов. Об этом я говорил в черновике своего доклада. Даже несмотря на то, что маржинальность коммерческого рынка раз в 20 больше чем у трудового рынка.

Все более отчетливо я вижу свою цель в создании такого маркетплейса услуг Consulting, Enabling, Audit, Outstuff, Outsource, Part-time, где грамотные специалисты смогли бы зарабатывать по достоинству благодаря решению "проблемы лимонов и персиков".

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

Все-таки, Жюль Верн был пророком. Роман "Путешествие и приключения капитана Гаттераса" - это, как мне кажется, про среднестатистический ИТ-проект.

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

Просрав команду и бриг, движимый "бизнес-целями" капитан попробует даже влезть в огненную лаву вулкана, за что поплатится здравым рассудком и уступит первенство капитану конкурирующего судна из США.

Команда тоже хороша. Во-первых, как это часто бывает в ИТ, она "проголосует ногами", и даже северный полюс ей в этом не преграда. Как истинные ИТ-шники, они сожгут свой бриг перед тем, как свалить. А потом начнут поедать друг друга, выпивая кровь своих коллег, подобно ИТ-шникам в процессе WTF.

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

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

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

Коллеги, с Праздником! Ярких побед и высоких достижений!
Вот это песня, как мне кажется, тоже про среднестатистического ИТ-шника:
https://youtu.be/yr0QwWJPIZM?si=wMroDcSFXpq9yxBK
Ведь "Software design is a constant battle with complexity" — Eric Evans.

Знаете, какое профессиональное качество я больше всего не терплю? Лицемерие. Внешний конформизм. Бесхребетность. Когда человек говорит одно, а думает другое. Когда в лицо говорит одно, а за спиной - другое. Когда личные амбиции ставятся выше общих интересов дела. Когда у человека белое - это черное, а черное - это белое, и ты не знаешь, когда и что от него можно ожидать. Сегодня эту гнилость принято маскировать под новомодными терминами "софт скиллов" и "эмоционального интеллекта".

Вспоминаю песню В.С.Высоцкого:

Но не все, оставаясь живыми,
В доброте сохраняли сердца,
Защитив свое доброе имя
От заведомой лжи подлеца.
Хорошо, если конь закусил удила
И рука на копьё поудобней легла,
Хорошо, если знаешь, откуда стрела,
Хуже, если по-подлому, из-за угла.

В свое время Н.Я.Азаров сказал, что опереться можно только на то, что сопротивляется. Бумажный стол бесполезен - он сразу прогнется. Беспринципный человек не может стать опорой коллектива.

Был у меня один программист, который был слишком прямолинеен. Не все хотели с ним работать. Он не старался скрывать своего отношения.

Это был один из самых лучших программистов за всю мою практику. Грамотный, дерзкий, смелый. Не боялся никаких задач. За неделю он написал собственную реализацию Production Rule System (DSL-интерпретатор). Схватывал все на лету. Когда он впервые услышал про CQRS, то через неделю это было уже в коде, еще через неделю в коде были уже доменные события, а еще через неделю он уже спрашивал у меня про проектирование m2m связей в агрегатах.

При этом он был отличным наставником, который пользовался уважением в коллективе. Если он узнавал что-то новое и находил это полезным, то об этом узнавал весь коллектив.

Он не боялся задавать неудобные вопросы, чем развивал мои способности аргументать. У нас были честные профессиональные отношения. И мы делали такие вещи, про которые многие и не слышали. Это был человек дела. С таким можно и в огонь и в воду. Я бы с удовольствием поработал с ним снова.

Это называется профессионализм.

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

В продолжение темы. Говорят, что ум человека видно по его вопросам, а не по его ответам. В команде моего текущего проекта есть программист, не сильно опытный, но я его ценю потому, что он прямой и открытый, не стесняется задавать неудобных вопросов, которые делают меня умнее. И он не отцепится до тех пор, пока не выяснит все неясности. Именно он задал вопрос, в результате которого возник этот опрос (и этот). Как видите, если правильно сформулировать вопрос, то ответ будет очевидным для большинства опрошенных. И этот ответ не будет совпадать с подавляющим большинством эталонно-демонстрационных приложений, даже таких авторитетных, как от Microsoft. Этот программист обнаружил ошибку, которую не заметили в компании с самой высокой архитектурной культурой в мире, и над документацией которой работало 2599 контрибьюторов.

Будь на его месте какой-нибудь бесхребетный соплежуй после псевдософтскилловых курсов, то я бы даже не задумался об этом, и не обнаружил бы нестыковку.

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

вот даже книжку подвалили: https://www.ozon.ru/product/kak-ubedit-teh-kogo-hochetsya-pribit-pravila-produktivnogo-spora-bez-agressii-i-perehoda-1212729149/?

)

Вот хорошая книга про конфронтации и споры.

https://www.ozon.ru/product/dzhedayskie-tehniki-konstruktivnogo-obshcheniya-orlov-aleksandr-elektronnaya-audiokniga-917253665/?asb=Be%252FFUBK71EHhLQk04ZAlECN22i2r54PLYZjRAV%252FwRMo%253D&asb2=b3hGw0AlGeI7bXnX6OqomduBi5-hpqViN4jaN8zk1g--XB946T70msRJKBytJvo9&avtc=1&avte=2&avts=1696928187&keywords=%D0%B4%D0%B6%D0%B5%D0%B4%D0%B0%D0%B9%D1%81%D0%BA%D0%B8%D0%B5+%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D0%BA%D0%B8

Ну и еще ряд сообщений, начиная отсюда (обсуждали ранее):
https://news.1rj.ru/str/emacsway_log/450

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

Именно об этом гласит один из 12 принципов Agile-manifesto:
💬 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Я всегда испытываю неподдельное восхищение от таких грамотных обсуждений. Не буду скрывать, что такие обсуждения делают меня умнее. Особенно радует, когда моя библиотека пополняется превосходными книгами.

Основных участников обсуждения я знаю уже более 4 лет, и они существенно повлияли на становление меня как специалиста.

Отдельно хочу выделить Дениса Бескова - человека с уникальной грамотностью. Его проницательность всегда заставляет меня задуматься (иногда не сразу). А ведь было бы так удобно и комфортно считать себя "самым-самым" и избавиться от всех раздражителей своей зоны комфорта, заклеймив их. Это путь деградации. И именно об этом был мой пост.

Путь развития требует определенных морально-психологических и волевых качеств. Если бы это было не так, то сегодня профессоров было бы больше, чем грузчиков.