В США медведь отбил пятюню водителю

Несколько мыслей о профессиональных общественных объединениях.

Слово организация происходит из др.-греч. ὄργανον «орудие, инструмент; машина; орган», далее из праиндоевр. *worg- (*werg-) «делать».

А слово объединение - от слова единство. Праслав. *edinъ, *edьnъ — из *ed- (ср.: русск. едва) и стар. числит. *jьnъ (ср.: русск. иной). "Едва иной" - т.е. чистый, концентрированный, без примесей.

Залогом успешности организации являются "единство целей" и "люди дела".

Организация - это концентрированное выражение воли к достижению цели. Иными словами, важно не объединение само по себе, а те принципы, на которых оно основано.

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

Концентрация сил необходима для преодоления сил сопротивления 🏋, подпитывающих (решаемую) проблему.

Цели - это то, в чем заключается смысл существования организации. Без общих целей организация быстро превращается в площадку для самоутверждения и достижения личных интересов, которые легко могут входить в противоречие с личными интересами других участников. Такое объединение не только лишено смысла, но еще и ни на что не способно, т.к. уже не выполняет функции концентрации организованной силы ввиду того, что её усилия взаимно компенсируются внутренними разногласиями. Такая организация борется не с проблемами индустрии, а сама с собой, и никакой решающей внешней силы из себя не представляет. Увы, но сражения выигрывает строй, а не индивидуальная исключительность.

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

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

Устав - это скелет ☠️, на котором нарастает плоть 💪.

Устав - это стяг 🏴‍☠️, объединяющий людей, разделяющих его цели, и на корню пресекающий попытки посгательства на способ существования организации, поскольку именно он и стал причиной вступления человека в организацию. А следствие, как известно, не может бороться со своей причиной.

Устав - это гарантия устойчивости организации 🏰 в условиях любых эмоциональных потрясений 🌪⚡.

А казалось бы, такая формальность...

#Goal

Является ли Post Code Review (Pre-Integration Review) эффективной практикой? Давайте посмотрим, какие исходы обычно возникают в результате Code Review:

1. Когда новый инкремент знаний получен, тогда возникает:
1.1. Конесенсус (обоюдное согласие на едином решении), который формируется, как правило, новым инкрементом знаний, полученным в процессе обсуждения Pull Request.
Или:
1.2. Психологическая защита. Чувство ущербности на фоне грамотного спикера вынуждает специалиста защищать свою зону комфорта и социальное положение путем агрессивных попыток дискредитации носителя неудобных компетенций. Увы, подобные случаи происходили даже в практике достаточно известных авторов по архитектуре. Иными словами, мало знать, нужно уметь еще донести.

📝 "Там, где заканчивается знание, начинается мнение".
-- "Философия: Энциклопедический словарь." — М.: Гардарики. Под редакцией А.А. Ивина. 2004.

2. Если знание по своему определению непротиворечиво и способно привести к обоюдному согласию (пусть и не всегда), то недостаток знаний (для качественной аргументации позиции) приводит к соперничеству мнений за лидерство. Тогда возникает:
2.1. Внешний конформизм, когда одному из участников Code Review не удалось аргументированно пояснить свою позицию другому, и тот решил прекратить прения, оставшись внутри себя несогласным.
Или:
2.2. Эффект иррационального усиления - когда психологически сложно расстаться с проделанным трудом.

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

Поскольку ключевым условием достижения консенсуса ревьюера и автора Pull Request является новый инкремент знаний, резонно возникает вопрос: а нужно ли получение этого инкремента привязывать по времени к инспекции уже воплощенной реализации? Design Review? Continuous Code Review? Refinement Code Review?

#SDLC #Management #Psychology

Grady Booch - Software Architecture for a Post AI and Post Quantum World
- https://youtu.be/MyVKoV1Nru8

- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-11.aspx

#SoftwareArchitecture

Simon Brown - Visualising Software Architecture with the C4 Model
- https://youtu.be/I3F7G5yxzqs

- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-4.aspx

#SoftwareArchitecture

Mark Richards & Neal Ford - Modern Tradeoff Analysis For Distributed Architectures
- https://youtu.be/mT7CT2Sg_L8

- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-6.aspx

#SoftwareArchitecture

И куча других интересных видео:
- https://iasaglobal.org/Public/Public/News/News.aspx

[UPDATE]: если у кого-то не работает, то все видео здесь:
- https://m.youtube.com/c/IasaGlobalVideo

#SoftwareArchitecture

Старина Kent Beck написал очередную бомбовую статью про качественный код:
"Tune Software Development for Rate of Change, not Rate of Progress"
https://medium.com/@kentbeck_7670/tune-software-development-for-rate-of-change-not-rate-of-progress-56f93c15a769

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

#SoftwareDesign

В продолжение темы невысокой эффективности Post Code Review:
"Эксперимент с красными бусинками - Dr. Deming's Red Bead Experiment"
- https://www.youtube.com/watch?v=Nf431Upix3M

Thanks to @sergey486

#SDLC #Management #Psychology

"Crossing aggregate boundaries" by Vladimir Khorikov ( @vkhorikov )
- https://khorikov.org/posts/2022-06-13-crossing-aggregate-boundaries/

> I hear this guideline a lot as well.

Тоже слышал эту фразу много раз, как правило от тех, кто эту книгу сам не читал. Именно поэтому очень важно получать информацию из первоисточника, где V.Vernon сопровождает эту информацию еще целым рядом дополнительной информации, в которой он не только допускает, но и рекомендует в некоторых случаях фиксировать несколько агрегатов одной транзакцией.

#DDD

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

Это совершенно новый для меня вид деятельности и, признаюсь, дается не всегда просто. Огромное спасибо @sergey486 и @elukianov за участие, @inikolski за информационную поддержку по обзору уставов существующих ассоциаций и за идею групп-сателлитов, @WatchTh15 за решающий аргумент в выборе организационно-правовой формы объединения, а также всем, кто поддержал информационно наше объединение своими репостами.

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

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

P.S.: Самый важный урок, который я вынес за последнее время: "здоровый сон - важнее всего". Все остальное - неважно, если затуманенный и полусонный мозг, ослабленный перенесенным ковидом, не может своевременно и ясно аргументировать позицию. Нет ничего хуже, чем потерять ход мысли в нужный момент или не увидеть противоречия, лежащие на поверхности. Наконец-то я понял смысл лозунга "Будь готов!"🔥🙂

#Goal

Самое долгожданное событие в архитектурном мире наступило - материалы монументального многолетнего труда в области управления сложностью, одного из лучших авторов современности Vladik Khononov ( @vladik_kh ) начали выходить в публичность:
- https://youtu.be/d6BeLhm3a0s

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

Новая его книга консолидирует труды Larry Constantine, Tom DeMarco, Meilir Page-Jones, David L. Parnas, Robert C. Martin, и вооружает нас принципом, способным легко отыскивать победные решения в задачах любого уровня сложности.

[UPDATE]: Ждем вторую часть этого keynote с ddd europe - "fractal geometry of software design". Через пару месяцев должны опубликовать.

#SoftwareDesign #MSA #DDD #SoftwareArchitecture

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

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

Достоверно известно, что эта проблема ведет к падению velocity со скоростью, близкой к геометрической прогрессии, а значит, к стремительному падению рентабельности и конкурентоспособности проекта. Разве является это чей-то целью? Но если это не является ничьей целью, то почему эта проблема все еще существует и прогрессирует?

Причины здесь три:

1. Как говорил Кент Бек: "Краткосрочные индивидуальные цели часто конфликтуют с долгосрочными социальными целями. Общество решает эту проблему при помощи набора ценностей, подкрепленных мифами, ритуалами, наказаниями и наградами. Без уважения к этим ценностям люди забывают о социальных нуждах и стремятся реализовать свой собственный индивидуальный краткосрочный интерес."
-- "Extreme Programming Explained" 1st edition by Kent Beck, "Chapter 7. Four Values", перевод ООО Издательство "Питер"

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

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

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

3. Как ни банально это звучит, но имеет место элементарная нехватка как управленческой, так и технической грамотности, преодолению которой зачастую препятствует "Эффект Даннинга-Крюгера".

Как видите, для решения проблемы в масштабах отрасли, одного только недовольства ею недостаточно. Чтобы решить проблему, требуется:

1. Высокий уровень грамотности для анализа проблем, выявления точных целей и постановки эффективных задач. В данном конкретном случае требуется глубокое знание в Software Design, управлении процессами разработки и теории внедрения изменений.
2. Чистота и единство общих целей, высокий уровень морально-деловых качеств.
3. Консолидация индивидуальных усилий в организованную силу, способную преодолеть силы сопротивления, подпитывающие существование решаемой проблемы.

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

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

А для того, чтобы обладать потенциалом, достаточным для привлечения массового внимания, нужно консолидировать усилия лидеров общественного мнения, что и является задачей такого объединения. Почему, например, о "Неделе высокой моды" в Москве слышали многие, а о "Неделе качественного кода" не слышал никто? Разве с модой у нас дела обстоят хуже, чем с ежедневным количеством WTF на работе?

Мы решили эту ситуацию исправить и начать цикл тематических месячников с целью концентрации внимания общественности на конкретных проблемах и способах их решения.

#Goal

Рождается ли в споре истина? Хочу поделиться своими мыслями из обсуждения в публичном чате канала объединения.

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

В спорах сходится два мнения. Мнения могут быть противоречивы, т.к. они могут производиться разным подмножеством опыта двух субъектов спора.

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

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

[UPDATE]: Вспомнилось: каждый хочет, чтоб правда была на его стороне, но не каждый хочет быть на стороне правды.

#SoftSkills

Две статьи о том, что проблема гонки сообщений в шине может решаться на уровне бизнес-логики. Одна из них - от Vaughn Vernon. Он даже видит в этом превосходство DDD.

1. "Modeling Uncertainty with Reactive DDD" by Vaughn Vernon reviewed by Thomas Betts
2. "Nobody Needs Reliable Messaging" by Marc de Graauw

#DDD #Microservices #DistributedSystems