Prioritizing Technical Debt as If Time & Money Matters • Adam Tornhill • GOTO 2022

Крутой доклад от Адама Торнхилла, который продолжает тему complexity в разработке ПО, которая была главной в книге A Philosophy of Software Design, которую я вспоминал вчера.
Сначала автор приводит Lehman's "Laws" of Software Evolution, которые показывают почему вопрос управления сложностью важен
- Continuing change - система должна постоянно адаптироваться или она будет прогрессирующе становиться менее приемлемой
- Increasing complexity - по мере эволюции системы complexity возрастает, пока не будут выполнена работа по поддержке или уменьшению complexity
Это накопление complexity приводит к появлению технического долга, который замедляет time to market, снижает предсказуемость работы над системами, приводит к организационным проблемам, а также снижает возможности к инновациям.
Дальше автор предлагает способы его померить при помощи Behavioral Code Analysis, который состоит из трех компонент: code, people, context. Все это можно подтянуть из VCS. Автор предлагает мерить 2 параметра
- Code complexity - метрика сложности кода, про нее чуть дальше отдельно
- Code change frequency - метрика частоты изменения кода (тут просто количество изменений кода за период времени)
В сумме эти два параметра позволяют понять какие части кода являются сложными и которые приходится часто править.

Code Complexity автор предлагает мерить опять не одной метрикой, а используя набор метрик для оценки здоровья кода:
- На уровне модулей - low cohesion (слишком много ответственности на классе), brain class (low cohesion, + как минимум один Brain метод, который большой, сложный и централизует поведение модуля)
- На уровне функций - brain methods, copy-pasted logic
- На уровне имплементацииl - deeply nested logic, primitive obsession

Дальше автор показывает пример анализа кодовой базы Android для того, чтобы продемонстировать свою концепцию. Распределение частотности работы с разными файлами выглядит как распределение с длинным хвостом, поэтому часто изменяющихся файлов не так много и только часть из них сложные. Собственно нам надо начинать работу с нашим техдолгом именно с этих файлов, а остальные можно игнорировать - это прагматичный, экономически-обоснованный подход. Интересно, что автор утверждает, что это стандартная картина для всех проектов, что он видел. А дальше он находит проблемный файл ActivityManagerService.java и делает drill down, чтобы показать как найти место внутри этого файла, где сконцентрированы основные проблемы - собствеенно это он и называет X-Ray.

Дальше идет рассказ про legacy code, который он определяет следующим образом:
- Lacks in quality - стандартное определение
- We didn't write ourselves - не совсем стандартная часть:) которая мешает начать рефакторить свой код вовремя
Дальше автор рассказывает забавную историю про анализ трех разных проектов, где два были свои родные, а один приемный. Они были сравнимы по качеству, но переписать хотели только чужой проект, так как на него пало подозрение в том, что он legacy:)

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

P.S.
У автора есть сайт https://codescene.com/ и книга "Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis", в которой этот подход подробно разобран.

#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Architecture #TechDebt #Management

Плакат от МИФа «Креативные техники»

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

#Creativity

Distributed Systems, 4th Edition (Рубрика #Architecture)

Полгода назад я рассказывал как дочитал книгу ван Стина и Таненбаума по распределенным системам. Она настолько мне понравилась, что я написал краткое саммари первой главы, в которой авторы делали краткий обзор всех тем книги. Дальше эту книгу выбрали слушатели клуба Code of Architecture, чтобы мы начали читать и обсуждать ее ... А дальше авторы выпускают в январе 2023 года новое издание книги, доступное бесплатно на сайте авторов.
В общем, эта книга - отличный подарок к началу нового года:)

#Architecture #SoftwareArchitecture #DistributedSystems #Software #SystemDesign

NASA Systems Engineering Handbook

Кто в детстве не мечтал стать космонавтом? И несмотря на то, что мечты не сбылись, но вот книжку про то, как космонавты проектируют свои системы я себе заполучил, причем заполучил в бумаге.
Для тех, кому бумага не принципиальна, pdf доступен на сайте nasa.

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

#SystemEngineering #Processes #Management

Team Topologies, Software Architecture & Complexity • James Lewis • GOTO 2022

Еще одно интересное выступление с амстердамской конференции GOTO, в заглавии которого вынесены термины, которые я сам часто использую: топологии команд, архитектура, сложность.
Автор начинает рассказ с вступления, в котором он говорит про популярность микросервисной архитектуры и почему она стала такой популярной и что лежит за этим.
Автор концентрируется в своем выступлении на 4 аспектах:
- componentization via services
- organized around business capabilities
- products not project
- decentralized governance

Дальше автор вспоминает про сложности организационного дизайна и так приходит к книге "Team Topologies", про которую у меня есть серия статей с ее обзором:
- Teams as means of Delivery
- Team Topologies that work for flow
- Evolving team interactions for innovation and rapid delivery
И вспоминает он про нее в контексте фразы кого-то из Amazon "The bigger we get, the easier it becomes to get bigger" и смысл тут в том, что цель успешного орг дизайна в том, чтобы оптимизировать структуру под поток ценности, а именно это и помогает сделать подходы из team topologies. Забавно, что автор показывает как выглядит процесс создания value (на диаграммах, которые похожи на те, что остаются после Event Storming) и насколько там мало самого программирования:)

Дальше автор переходит к архитектуре программного обеспечения и как она помогает бороться со сложностью окружающего мира и наших решений, которые моделируют его. Рекомендую на эту тему почитать книгу "A Philosophy of Software Design" (у меня есть краткое саммари: 1, 2). В этой книге очень классно разбирается вопрос сложности и борьбы с ней при создании программного обеспечения. Потом автор приходит к понятию complex adaptive system (млекопитающие, города, создание софта?) и показывает какие у них бывают свойства (self-similarity, self-organization, complexity, emergence) и как там работают степенные законы для экономии на масштабе и убывающей полезности по мере масштабирования (кроме Amazon, у которой полезность не убывает - правда, это может быть связано с сетевыми эффектами многосторонних платформ, подробнее в книге "Machine, Platform, Crowd"). В итоге комплексные адаптивные системы оказываются везде вокруг нас и иерархии в них приводят к фрактальным эффектам с эффектом от масштабирования с экспонентой и числом меньше единицы в знаменателе.

После этого автор описывает корпоративный метаболизм - так как организации это тоже complex adaptive system, то по мере масштабирования у них растет количество уровней иерархии и revenue масштабируется сублинейно и метаболизм замедляется. Автор приводит прикольный пример с метаболизмом слона и мыши. Слону надо есть гораздо меньше еды в процентном соотношении от своей массы, чем мыши. Но, одновременно, у слона метаболизм настолько медленный, что он не более раком - клетки просто не успевают состариться. Похожее происходит и в крупных компаниях. Дальше автор рекомендует книгу "Accelerate", которая позволяет мониторить здоровье организации через метрики: MTTR, cycle time, change failure rate, number of deploys.
В крупных организациях меньше идет бюджета на R&D, больше процессов и бюрократии, а также иерархий.

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

#TeamTopologies #Software #Architecture #SoftwareArchitecture #Management #Processes #SystemDesign

В этот понедельник, 15 января, мы провели первый стрим по книге “Distributed Systems”, в котором мы начали обсуждать новое издание этой книги, которая вышла в начале января. В этом эпизоде мы обсудили первую главу "Introduction".
Гостями стрима были
- Александр Краснов, CTO Тинькофф Страхования
- Антон Костерин, который вместе с с моей командой разрабатывает сервисы по управлению сайтом Тинькофф и мобильным банком

Артефакты с этого стрима доступны по ссылкам
- Статья с кратким обзором
- Запись стрима
- Miro доска с презентацией

#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software

Истоки морали. В поисках человеского у приматов (The Bonobo and the Atheist: In Search of Humanism Among the Primates)

Эта книга за авторством Франса де Вааля определенно интересна и поднимает важные вопросы.
Занимательно, что в оригинале она называется "The Bonobo and The Atheist. In search of Humanism among the Primates", что гораздо точнее позиционирует книгу. Посудите сами:
- автор много лет исследовал приматов, причем в его исследованиях преимущественно речь шла о шимпанзе и бонобо, наших ближайших родственниках. Что заявлено прямо в названии
- автор много говорит про религию и веру и ее связь с моралью, что неплохо заявлено при помощи упоминания атеиста
- красивее обыграны слова humanism и primates, т.к. первая лучше отсылает к human'ам:)
Интересно, что в самой книге перевод достаточно хороший и есть неплохие комментарии редактора, поясняющие и уточняющие некоторые моменты.

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

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

Эта точка зрения обнадеживает и позволяет верить в дальнейшее развитие человека как вида:)

#Biology #Management #PopularScience #Brain

Teaching Kids to Program with Hedy: A Gradual Programming Language • Felienne Hermans • GOTO 2022

Очередное интересное видео с goto конференции в Амстердаме. На этот раз про обучение детей программированию при помощи нового языка Hedy.
Автор доклада так объяснила потребность в новом языке:
- Для обучения малышей есть Sketch, который отлично закрывает запросы маленькой аудитории (подробнее про то, как он появился и в чем концепция можно почитать в книге его автора, Митчела Резника “Спираль обучения” (“Lifelong kindergarten”), про которую я уже писал на Medium)
- Но по мере взросления детей они хотят переходить к "взрослому" программированию вместо визуального. Обычно на этом этапе детям предлагают Python как дефолтный язык для обучения, но переход не для всех проходит безболезненно - некоторым детям сложно понять сложность синтаксиса языка, которая отвлекает их от семантики создания программ и написания алгоритмов. В итоге, часть детей на этом этапе отваливается и перестает эффективно обучаться.

В итоге, автор разработала исследовательский проект, в котором язык программирования Hedy имеет 18 уровней сложности и если первый уровень позволяет почти все, то 18 уровень уже является синтаксически верным подмножеством Python. А дальше этот исследовательский проект за 2 года стал достаточно популярным, в какое-то время про него написал даже Гвидо ван Россум, что удвоило счета Heroku, за которые пришлось платить автору языка. Сам язык является open source, доступен на gihub и достаточно интересен как технический проект, так как вопросы создания языков, их трансляторов и так далее являются наукоемкой областью (помню как в университете ботал курс теория и реализация языков программирования и там было много интересного). В конце выступления автор рассказала о том, что проект ждеть контрибьюторов и если кто-то хочет поучаствовать, то "you are welcome".

#Software #PopularScience #Learning #Study #ComputerScience

Agility is Inefficient • Klaus Bucka-Lassen & Dirk Bucka-Lassen • GOTO 2022

Интересный доклад с кликбейтным заголовком от Klaus Bucka-Lassen, agile coach, который начал выступление на троллинге названия классической книги "Scrum: The Art of Doing Twice the Work in Half the Time". Но на самом деле автор говорит про разницу между effectiveness и efficiency и показывает как многие компании сосредотачиваются на операционной эффективности (efficiency), когда делают не совсем то или совсем не то, что хочет customer. Автор показывает, что
- Efficiency - это про looking inwards, defining and optimizing processes, automate
- Effectiveness - это про looking outwards, observe the market, pivot, innovate

Показывает он это на примерах компаний
- Blockbuster и Netflix на рынке просмотра видео
- Nokia, Microsoft и Apple на рынке мобильных телефонов
- Volkswagen и Tesla на рынке автомобилей

Дальше он описывает smells организаций, которые больше про efficiency, а не про effectiveness
1) Budgets & cost cutting (rather than continuous funding)
2) Company run by process people (rather than product people) - we need to such process or automate it
3) High degree of specialization (I over T-shapedness)
4) Utilization Maximization

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

#Processes #Management #Leadership #Agile #Software #SoftwareDevelopment