Measuring Engineering Productivity (from Software Engineering at Google) - Part I

Пока у меня отпуск я знакомлюсь с крутой книгой от инженеров из Google, где они преоткрывают завесу тайны над своими инженерной культурой, процессами и практиками. Книга мне нравится и я решил поделиться актуальной главой про то, как в Google подходят к измерению инженерной продуктивности и вот основные мысли из этой главы
- Google - это data-driven компания, где решения принято строить на основе объективной информации, а не субъективных мнений
- При росте бизнеса растет и инженрная команда, но если организация растет условно линейно, то затраты на коммуникацию растут квадратично (можно вспомнить количество ребер в полном графе - n * (n-1) / 2). Поэтому мы не можем просто масштабировать организацию линейно - надо уметь делать каждого инженера более продуктивным
- Для повышения продуктивности надо уметь находить неэффективности в инженерных процессах и фиксить найденные проблемы. Для этого в Google собрали отдельную команду исследователей, изучающих инженерную продуктивность. В этой команде есть как инженеры, так и social scientists из множества областей, включая когнитивную психологию и поведенческую экономику. Эти ученые изучают человеческую сторону инженерных процессов
- Эта команда очень щепитильна к темам своих исследований - померить можно конечно многое, но сначала надо ответить на вопрос, а стоит ли вообще это измерять. И у них есть особый процесс для триажа (triage), где они задают вопросы командам, которые пришли к ним с запросом на исследование
-- What result are you expecting, and why? - этот вопрос позволяет понять изначальные предубеждения и учесть их при оценке эксперимента
-- If the data supports your expected result, what action will be taken? - есть смысл измерять что-то, если этот приведет к каким-то решениям и действиям
-- If we get a negative result, will appropriate action be taken? - если негативный результат исследования не повлияет на решение, то проводить исследования тоже не стоит
-- Who is going to decide to take action on the result, and when would they do it? - надо понимать кто ЛПР (лицо принимающее решение) и имеет ли он отношение к заказу исследования. Надо понимать какие подходы к исследованию этот ЛПР считает валидными - ему нужны количественные данные, качественные (в виде интервью), он верит результатам опросов или доверяет только данным из логов систем (activity based stats). В общем, это совет из серии того, что надо знать свою аудиторию и ее потребности:)
Если вовремя задать эти вопросы, то многие измерения просто не стоят того, например, авторы приводят такие примеры

- You can't afford to change the process/tools right now
- Any results will soon be invalidated by other factors
- The results will be used only as vanity metrics to support something you were going to do anyway
- The only metrics available are not precise enough to measure the problem and can be confirmed by other factors

- Дальше авторы рассказывают про свой подход GSM (goals - signals - metrics) для
-- Goal - это ожидаемый конечный результат, он формулируется в высокоуровневых терминах и не содержит отсылок к тому, как его измерять
-- Signal - это то, как вы поймете, что результат достигнут. Его бы вы хотели измерить, но не всегда это просто
-- Metric - это прокси для сигнала. Это то, что мы реально можем померить, может быть это не идеальное измерение сигнала, но достаточно близкое

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

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

Measuring Engineering Productivity (from Software Engineering at Google) - Part II

Продолжая первый пост, расскажу про исследование readability процесса, в котором авторы сформулировали цель относительно developer productivity, разложив ее на пять отдельных компонент со звучным акронимом QUANTS:
- Quality of the code - качество создаваемого кода, тест-кейсов, архитектуры, ...
- Attention from engineers - как часто инженеры достигают состояния потока, насколько у них много переключений контекста.
- Intellectual complexity - насколько большая когнитивная нагрузка возникает при выполнении задачи. Какой баланс между присущей и привнесенной сложностью (условно есть внутренняя сложность проблемы, а есть дополнительная, которая внесена нашими процессами, инструментами, ...)
- Tempo and velocity - скорость решения задач, пропускная способность (количество задач в единицу времени), темп поставки изменений
- Satisfaction - насколько инженеры довольны своими инструментами, насколько они удовлетворены своей работой и создаваемыми продуктами, насколько они ощущают выгорание

Дальше авторы исследования про readability разложили свои цели по этим 5 критериям:
- Quality of the code - инженеры пишут более качественный код в результате процесса readability review
- Attention from engineers - по этому пункту авторы не выставляли никакой цели
- Intellectual complexity - инженеры изучают кодовую базу Google и лучшие практики в результате процесса, а также получают менторинг от опытных сотрудников
- Tempo and velocity - инженеры выполняют рабочие задачи быстрее и более эффективно в результате процесса
- Satisfaction - инженеры видят пользу readability процесса и испытывают позитивные ощущения от участия в нем

Дальше авторы зафиксировали ожидаемые сигналы и метрики и провели исследование. Интересно, что почти все темы были покрыты метриками из опросов (квартальный опрос и отдельный readability опрос) и только часть про tempo/velocity отчасти опираются на метрики из логов: по медианному времени ревью Changelist (аля MR).

В общем, результаты исследования показали, что readability процесс приносит пользу даже в самых инструментализированных языках (C++, Java). Поэтому сам процесс остался на месте (по крайнейм мере на момент написания книги в 2020 году).

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

How To Be A Great Programmer • Dave Farley • GOTO 2023

Это короткое видео Дэйва Фарли посвящено тому, как быть крутым разработчиком. Интересно, что сам Дейв - тертый калач, который в давние времена написал книгу Continuous Delivery (я про нее рассказывал), а недавно - "Modern Software Engineering: Doing What Works to Build Better Software Faster", которая стоит у меня на полке и ждет своего часа. В этом видео Дейв выделил шесть вещей, которые он считает важными для крутых инженеров
- Code as communication - тут Дейв говорит о том, что код - это средство для коммуникации людей между собой, а не просто для общения с компьютером. Удобочитаемость кода важная для экономии времени и денег, если мы не пишем одноразовый скрипт. Так совокупная стоимость владения на протяжении работы с кодом меньше, так как большую часть времени мы читаем и дорабатываем код, а не раз и навсегда высекаем его в камне:) Интересно, что у Google есть отдельный процесс насчет поддержания readability в их огромной кодовой базе, про который я рассказывал в прошлом посте "Measuring Engineering Productivity". У ребят из Google как раз был вопрос насколько этот процесс окупается и стоит ли его отменить в силу появления линтеров и статических анализаторов. В итоге, ребята поняли, что он приносит пользу и решили его оставить
- Be coutious of framework - здесь Дейв говорит о пользе фреймворков, которая сопряжена с риском. Фишка в том, что фреймворки определяют структуру вашего кода (через концепцию inversion of control) и это влияет на развитие и поддержание проекта. Дейв предлагает прибегать к изоляции стороннего кода за собственной абстракцией. В терминальной стадии риск подсаживания на фреймворки выглядит как разработчик на Spring Boot или Angular/React, которые под свой фреймворк ... и все:)
- Code is design - код и проектирование неразделимы. Автор говорит о том, что зачастую люди под проектированием понимают выбор конкретных технологий навроде K8s, что заменяет решение изначальной проблемы. Другая проблема - это выделение отдельной должности архитектора, к которому отъезжают вопросы проектирования и архитектуры. Кстати, на эту тему был выпуск подкаста "Code of Leadership", где мы с Лешей Тарасовым, техдиром социальных платформ в Тинькофф, обсуждали staff+ трек для индивидуальных контрибьюторов и почему архитектор - это роль высокоуровневых инженеров, а не выделенная должность. В итоге, Дейв заканчивает тезисами хороший код - это выбор организационных принципов для решения проблем. Дизайн - это выбор, который мы делаем каждый день, когда пишем код.
- Quality over features - великие программисты гордятся своей работой и стремятся сохранить и поддерживать свою способность вносить изменения в течение длительного времени. Это имеет смысл, если вы делаете не одноразовые скрипты. Так совокупная стоимость владения на протяжении работы с кодом меньше, так как большую часть времени мы читаем и дорабатываем код. Качество кода проще поддерживать, если у вас есть настроенный CI/CD и вы работаете в продуктовом, а не проектном подходе
- Software development is a social activity - автор говорит о том, что разработка софта - это социальная активность и для того, чтобы быть крутым инженером надо уметь хорошо общаться, уметь активно слушать окружающих, а также внятно доносить свои мысли.
- Avoid code ownership - великие разработчики открыты для критики и готовы учиться новому. В профессиональной среде важно разделять ответственность за код и избегать единоличной ответственности.

P.S.
Раньше я уже рассказывал про другое видео Дейва "The Most Powerful Software Development Process Is The Easiest", которое может быть интересно посмотреть в продолжение этого видео.

#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE #SelfDevelopment

ЦЕХ 4 - Урок #5. "Как преодолеть писательские блоки. Практическое занятие. Эксперт — Юлия Баяндина"

Продолжая серию постов про свое обучение книгописательству (смотри предыдущие посты: 1, 2, 3 и 4), я расскажу про пятый урок. Он был посвящен тому, как преодолевать писательские блоки. Это практическое занятие вела Юлия Баяндина — партнер и содиректор МИФа, которая девять лет назад с нуля выстроила систему контент-маркетинга.

Занятие было практическим - каждый участник работал со своим листом A4, который он постепенно заполнял текстом в следующем порядке
1) Воспоминания о своем детстве, юности и других периодах жизни. Я родился на берегу Белого моря в городе Северодвинске и до 18 лет жил с видом на побережье, за которым начинался хвойный лес, который уходил в бесконечность и сливался с горизонтом:)
2) Светлые воспоминания о каждом десятилетии, например, в детстве мне очень нравилось понимать что-то новое об окружающем мире - я был любопытен и любил мучить окружающих вопросами:)
3) Воспоминания о начале писательской деятельности. У меня первым опытом было написание фанфика на трансформеров, которые мне нравились в детстве. В итоге, я попробовал написать что-то по ним в первом классе ... круто, что старых тетрадок не сохранилось:) Ну а сейчас у меня есть желание перейти от статей к крупной форме и соединить их в книгу.
4) Мысли о том, что такое творчество. Мне кажется, что моя текущая работа тоже имеет творческую природу, так как решение комплексных задач до сих пор тешит мою любознательность и позволяет не скучать:) Ну и последние несколько лет я творчески подхожу к изложению своих мыслей в блоге и канале
5) Описание того, а что для нас это книги. Для меня книги - это способ отдохнуть и зарядиться энергией. А своя книга - это способ выгрузить на бумагу мысли, которые крутятся уже давно. Надеюсь, что потом я смогу чуток отпустить эти темы и переключиться на смежные
6) Наши мысли про профессию или роль писателя. И кто из авторов может быть для нас примером. Конкретно для меня авторы - это люди, которые проявили силу воли и смогли дописать свою книгу и изложить свои мысли на бумаге. Я прочитал много книг и мне нравится слишком много авторов, чтобы выделять конкретных.
7) Чем мы хотим поделиться с аудиторией. На этот вопрос я отвечал еще в первой домашке и я хотел рассказать про менеджмент и техническое лидерство в IT. Книга о том, с какими задачами сталкиваются лидеры в технологических компаниях России и мира. В книге не стоит задача описать каждую ситуацию и ее решение, скорее я хочу поделиться своей системой мышления, которая позволит читателям стать эффективнее в плане лидерства.
😍 Описание своих читателей и целевой аудитории. Для меня целевыми читателями будут инженеры и инжиниринг менеджеры, которые сталкиваются с техническими и управленческими вызовами при разработке софта в своих организациях.
9) Описание группы поддержки - обычно именно им посвящены благодарности в начале или конце книги. Мне понравилась фраза вида "спасибо моей семье за то, что эта книга вышла на пару лет позже, чем могла бы":)
10) Список людей, что нас вдохновляют. Мне нравятся ребята вида Джеффа Дина, Эндрю Танненбаума, Вила Ларсона
11) Создание обложки книги с отзывами на книгу, которые мы придумываем сами от лица людей, что нас вдохновляют.
12) Создание аннотации к книге, которая в одном абзаце должна заинтересовать потенциального читателя, взявшего книгу в руки.
13) Название книги и свое имя на обложке.
14) Ну и в конце надо представить, что книга уже вышла, вы получили свою бумажную копию книги и дальше вспомнили, что прошло между стартом работы и выпуском, а также что вам помогло дойти до конца.
15) Ну и в конце надо написать заголовок к эссе, которому у нас получилось в результате этого урока.

P.S.
Мне этот урок очень понравился - он позволил немного по другому взглянуть на написание книги:)

#Writing #SelfDevelopment #Management

Code of leadership #14 - Interview with Artem Ivanov about Risk Tech

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

- Дополнительные материалы про RiskTech, технический стек, контакты и вакансии
доступны здесь
- Плюс если кто-то хочет пообщаться с Артемом лично, то можно писать ему в Linkedin

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

MLOps в теории и на практике

Недавно вышел первый эпизод совместного подкаста Тинькофф Образования и Высшей Школы Экономики. Он был посвящен теме MLOps. Сейчас темы AI/ML у всех на слуху: все пытаются использовать LLM для оптимизации существующих процессов, кто-то старается придумать прорывные идеи, а кто-то боится этих изменений. В университетах сейчас есть большое количество курсов по обучению data science и machine learning, но в реальных компаниях зачастую надо не просто создать хорошую модель, но и сделать кучу других приседаний, которые можно назвать MLOps. Если описывать суть, то нужна четкая связь между Data engineering, App engineering и, собственно, ML engineering. Причем выстроенные процессы работы с данными нам нужны как пререквизиты для эффективной работы над ML-моделями, а App engineering нужен, чтобы обученные модели хорошо работали в продакшене и обслуживали запросы.

В обсуждении участвовали
- Дмитрий Ушанов, технический директор ML платформы
- Евгений Соколов — академический руководитель ПМИ ФКН ВШЭ
- и я

Кстати, узнавать про новые выпуски эпизодов этого подкаста и о других образовательных новостях Tinkoff можно в telegram канале "Тинькофф Образование" (@tinkoff_fintech).

P.S.
Я уже разбирал в двух постах в этом канале (1 и 2) тот простенький whitepaper об MLOps от Google, который мы использовали в качестве каркаса обсуждения на подкасте.

#ML #Devops #Data #AI #Software #Architecture #Processes

Sunk cost fallacy (Невозвратные затраты)

Sunk cost fallacy - это интересное явление, при котором человек не хочет отказываться от стратегии или курса действий, потому что он вложил в них значительные средства, даже если очевидно, что отказ будет более выгодным. Забавно, что есть и смежные эффекты вида:
- Эффект Икеи - когнитивное искажение, проявляющееся когда покупатели непропорционально высоко оценивают значимость (ценность) товаров, которые они создают отчасти сами (например, собирают из деталей)
- Синдром NIH (not invented here) - позиция в социальной, корпоративной или организационной культурах, при которой избегается использование или покупка уже существующих разработок, исследований, стандартов или знаний из-за их внешнего происхождения и затрат.

Эти ошибки мышления проникают во многие важные решения, даже если мы знаем про них:) Для того, чтобы с ней бороться, можно задавать себя явные вопросы вида:
- Если бы я не вложил столько сил в проект, то я бы настаивал на его продолжении?
- Если бы уже не было сделано X, то мы бы сделали его заново?
- Какие у нас есть альтеративы ? Причем туда входит как активные опции по изменению текущего состояния, так и сохранение статуса кво.

В общем, полезно знать про собственные предубеждения и пытаться принимать решения, избегая их:) А для того, чтобы знать про них можно посмотреть выступление "Keynote: Debug your thinking - Laila Bougria - NDC London 2024", про которое я писал раньше, а также почитать книги из подборок
1) На тему системного и критического мышления
2) На тему работы мозга

Плюс можно глянуть седьмой выпуск Code of Leadership про работу мозга "Your brain at Work", который был с Эрнесто Инаркиевым, чемпионом Европы по шахматам, гроссмейстером, который входит в ТОП-100 лучших шахматистов мира и в ТОП-30 по быстрым шахматам.

#Thinking #CriticalThinking #Reasoning #SelfDevelopment #Brain #Management #Leadership

How Cognitive Biases Affect our Software Architectures • Birgitta Böckeler • YOW! 2022

Это интересный доклад для архитекторов, в котором рассматривались следующие предубеждения, которые важны нам при проектировании софта:
- Confirmation biases характеризуется тем, что люди подсознательно работают с информацией так, чтобы подтвердить свою точку зрения. Это приводит к тому, что люди с трудом принимают изменения и склонны к повторению своих предыдущих решений и действий. Именно поэтому часто нам так сложно менять устоявшиеся процессы разработки или архитектуру решения - обычно это требует от руководителей мастерского управления изменениями. Я часто сталкивался с этим bias у других, да и ловил его у себя самого.
- Zero risk bias — этот bias влияет на то, как люди управляют рисками. Зачастую есть желание полностью исключить небольшой риск, а не смягчить общий риск даже на большую величину. Это относится к security рискам, избеганию vendor lock in или наличию преждевременных оптимизаций, которые могут защитить нас от рисков масштабирования, но часто не пригождается в итоге, а стоят дорого. Этот bias можно обойти, если иметь фреймворк для работы с рисками и использовать его в своих проектах.
- Availability heuristics - этот bias про принятие быстрых, но иногда не самых правильных решений. И мы строем свои выводы на доступной информации. В разработке софта это например проявляется в том, что часто про техдолг забывают, так как он бывает явно не зафиксирован и его как бы нет:) Поэтому стоит идти от обратного - делать так, чтобы информация о важных вещах была легко доступна. В разработке софта это относительно легко сделать используя логи, метрики, трейсинг как для технических систем, так и для самих процессов разработки.
- Base rate fallacy - этот bias влияет на то, как мы оцениваем вероятность разных сценариев, а дальше как мы распределяем силы своих команд. Часто мы уделяем больше внимания edge cases, про которые мы знаем много, в ущерб каким-то более общим сценариям. Этот bias влияет на приоритизацию усилий, поэтому классно, если у вас есть +/- стандартные метрики для оценки и сравнения важности задач между собой.
- Outcome bias - этот bias про то, что люди оценивают принятые решения на основании результатов. У нас есть поговорка “победителей не судят” и она как раз про это. Но гораздо продуктивнее поменять подход к оценке решения, ориентируясь на ту информацию, которая была доступна в момент принятия решения. В разработке этот подход применяют, когда используют процессы с написанием RFC (request for comments) и ADR (architecture decision records). Это позволяет постфактум оценивать качество решений, а не просто отталкиваться от результатов.
- Self-serving bias - этот bias о том, что люди склонны приписывать успех своим способностям и усилиям, а неудачи - внешним факторам. Это тоже влияет на то, как мы оцениваем свои решения. И этот bias мешает нам расти над собой, потому что мы свои точки роста выводим из своей зоны контроля апеллируя к слепому случая. Гораздо конструктивнее следовать пословице “на ошибках учатся”.

P.S.
Доклад хорошо продолжает вчерашний пост про Sunk cost fallacy (Невозвратные затраты)

#Thinking #CriticalThinking #Reasoning #Philosophy #SelfDevelopment #Brain #Management #Leadership

Искусство системного мышления (The Art of Systems Thinking)

Эта книга Джозефа О'Коннора и Иана Макдермота является одной из самых простых и понятных книг по системному мышлению, что я читал. Вместо заумной теории и сложных объяснений авторы предлагают кучу практических примеров, которые они вплетают в повествование так, что концепции системного мышления вы узнаете в бытовых ситуациях, навроде, ссоры со своей второй половинкой, потребления алкоголя или обучения новому. Книга читается буквально влет, благо она компактная и состоит из следующих частей

Часть 1 - Мышление за пределами очевидного
1. Что такое система? - авторы дают простое определение "Система есть сущность, которая в результате взаимодействия ее частей может поддерживать свое существование и функицонировать как единое целое", а дальше используют его для сравнения систем и просто групп объектов, чтобы показать разницу. Дальше идет речь про системные или эмерджентные свойства, когда целое больше суммы частей. Обсуждаются простые и сложные системы, система как паутина взаимосвей, стабильность и принцип рычага.
2. Контурное мышление - авторы рассказывают про feedback loops, которые позволяют системе обрести интересные свойства, но одновременно усложняющие предсказание происходящего в системе. Эти петли бывают усиливающими (положительная обратная связь) и уравновешивающими (отрицательная обратная связь). Авторы показывают кучу примеров и объясняют почему терминология усиливающие/ослабляющие лучше:) Плюс они показывают какой интересный эффект возникает, когда обратная связь запаздывают и возникают колебания в системе.
Часть 2 - Построение ментальных моделей
3. Ментальные модели - при мышлении мы опираемся на встроенные ментальные модели (идеи, верования и убеждения), которые определяют нашу интерпретацию событий, выбор варианта действия и его реализацию. Нам надо знать про свои ментальные модели, т.к. мы используем их для придания смысла другим системам. В создании и поддержании этих моделей участвуют 4 механизма: вычеркивание, конструирование, искажение и обобщение. Ну и есть другие факторы, что приводят к искаженному восприятию опыта: регрессия, временные рамки, избирательная трактовка опыта
4. Причина и следствие - причинно-следственная связь в системах сложнее линейной - из-за циклов причина может порождать следствие и наоборот. Есть три стандартных заблуждения из линейного мира: разделимость причины и следствия, отсутствие учета времени (следствие сразу идет за причиной), пропорциональность следствия причине. Дальше авторы говорят, что работая со сложными системами, надо определять границы системы, а также искать аттракторы (стабильные состояния, к которым тяготеет система)
5. За пределами логики - формальной логики не достаточно, когда мы имеем дело с системами. Нужен системный подход и метапозиция, что позволяет выйти за пределы стандартной системы отсчета. Для изменения состояния систем часто лучшими точками приложения усилий являются наши ментальные модели
Часть 3 - Мыслить по новому
6. Обучение - рассказ про 2 типа обучения: простое и порождающее. В простом обучении мы используем обратную связь для корректировки своих действий для лучшего достижения нашей цели. В порождающем обучении у нас 2 контура обратной связи и мы не просто корректируем свои действия, но корректируем и свои ментальные модели.
7. Ракурс, перспектива - рассказ про важность точки зрения и расширение наших ментальных моделей. В системном мышлении используется как объективный подход (взгялд на систему снаружи), так и субъективный подход (взгляд на систему изнутри). Причем выбор подхода зависит и от того, а как мы определяем границы системы.
Часть 4 - Рисуем выводы - рассказ как можно визуализировать структуру системы и взаимосвязи, используя контуры обратной связи (куча примеров)
Часть 5 - Замыкаем круг - авторы показывают как использовать весь приведенный до этого инструментарий системного мышления, например, если результаты не соответсвуют усилиям.
Часть 6 - Источники - история того, как системное мышление появилось и развивалось в 20 веке.

#Brain #SelfDevelopment

How We Write Better Software with Low-Code • Michiel Overeem • GOTO 2023

Интересное выступление про low-code платформу от Michiel Overeem, который рассказал как голландская компания AFAS пришла в своем SaaS продукте (смесь ERP, CRM, CMS, и других трехбуквенных слов) к подходу с low-code. По-факту, продукту уже почти 3 десятка лет и за это время он прошел путь от MS DOS программы до того, что разворачивается где-то на серверах и превратился в legacy:) Дальше появилась задача разделить доменную логику и технологическую часть. Знания о бизнесе должны были остаться в моделях, чтобы можно было спокойно развивать технологии. В компании решили это сделать через создание low-code движка, которым будут пользоваться внутренние сотрудники, доменные эксперты, для создания/редактирования бизнес-процессов и пользовательских сценариев работы с системой. Модели из домена по этой логике должны быть свободной от технологий, описывать процессы и роли в реальном мире. В low-code платформу пришлось нехило вложиться и поработать над архитектурой, получился в итоге фреймворк для создания интерфейсов и бекенд фреймворк. 95% функциональности генерируется на основе модели, что создаются citizen developers (это люди, что используют low-code платформу и о самом термине я рассказывал подробнее раньше), а 5% пишутся вручную силами инженеров. Дальше автор выступления рассказывает про преимущества такого подхода:
- Создание модели предметной области позволяет разработчикам писать код, тестировать его и помещать в генератор, что упрощает процесс разработки.
- Модель предметной области позволяет заменять технологии и интерфейсы, сохраняя знания в модели.
- Citizen developers могут вносить изменения в модель без вмешательства инженеров, что повышает продуктивность и позволяет им создавать прототипы и экспериментировать.
- Citizen developers могут создавать программное обеспечение, используя свои знания в области бизнеса, что позволяет им создавать прибыльные подпродукты
Но есть и проблемы
- Citizen developers могут вносить вносят ошибки в модель, что усложняет процесс отладки и требует привлечения программистов для консультации.
- Citizen developers должны понимать как их изменения в модели влияют на runtime свойства софта, что требует дополнительных инструментов и обучения
Ну и дальше идут выводы
- Low-code не является универсальным решением для всех частей приложения
- Стоит использовать low-code только в определенных частях, где можно найти повторяющиеся фрагменты, так как это позволяет работать над этими частями не инженерам, а citizen developers
- Low-code стоит рассматривать как дополнительный инструмент для повышения производительности и создания лучшего программного обеспечения.

В общем, достаточно простой и понятный доклад про то, как компании приходят к low-code решениям как части своего продукта. У нас по такому принципу сделана, например, low-code платформа для маркетинга, в которой сами аналитики могут выстроить процесс маркетинговых коммуникаций с определенными сегментами наших клиентов.

#Software #Engineering #Architecture #PlatformEngineering

Как лгать при помощи статистики (How to Lie with Statistics) - Part I

Этой книге Дарелла Хаффа уже 70 лет, но она до сих пор не потеряла актуальность. Я решил ее прочитать в продолжение книги "Understanding Statistics and Experimental Design. How to Not Lie With Statistics", про которую я рассказывал раньше. И книга не подвела моих ожиданий - она написана простым языком, не содержит воды и рассказывает о различных способах злоупотребления статистикой в целях обмана аудитории и манипулирования ее мнением. Книга состоит из 10 глав:
1. Выборка изначально необъективна - эта манипуляция связана с тем, как мы формируем выборку. Если выборка не соответствует генеральной совокупности (не является репрезентативной), то статистика, которую мы вычислим по этой выборке может показывать те числа, которые мы хотим. Но даже если мы хотим сделать максимально честную выборку, то это достаточно сложно сделать. Например, автор рассказывает про это на примере опросов. А вот пример от меня, whitepaper "DevEx in Action" про developer productivity был описан на основе опросов тех разработчиков, которые работали в компаниях, что пользовались платформой https://getdx.com/ , которая предоставляет инструменты для измерения developer productivity. В итоге, опрос показал, что эти инструменты полезны:)
2. Грамотно выбранное среднее - здесь речь идет про выбор среднего удобного для вашего конкретного случая использования, например, это может быть среднее (mean), медиана (median) и мода. В общем, в зависимости от вида распределения вашей величины эти варианты среднего могут сильно отличаться:)
3. Нюансы, о которых скромно умалчивают - здесь начинается все с размера выборки, который могут не упоминать (а при маленьком размере получить интересные результаты гораздо проще), также про неуспешные результаты экспериментов можно не рассказывать (зачем говорить про неинтересные вещи), плюс можно играть с формулировкой так, чтобы было не ясно как рассчитывается сам показатель:)
4. Много шума практически из ничего - здесь автор рассказывает про статзначимость и доверительные интервалы:) И что при указании конкретных чисел нам сложно сравнить их между собой не зная доверительных интервалов.
5. График - лучше не бывает - тут идет речь про манипуляции с графиками: отсчет не от начальной точки по вертикали, разные масштабы осей, выбор нужного интервала времени для демонстрации графика величины на котрасте между началом и концом интервала
6. Схематичная картинка - здесь автор рассказывает как можно при помощи инфографики обманывать людей. Например, при двухкратном росте денежного показателя показывать в два раза больший мешочек денег - но предметы мы воспринимает как трехмерные и там ощущение от этого приема, что рост был в 8 (2ˆ3) раз
7. Псевдообоснованная цифра - тут автор показывает как взятое из статистики рандомное число можно трактовать по своему усмотрению. Главное сделать отсылку к авторитету и указать откуда взято число, а интерпретацию уже вкрутить свою:) Кстати, это частая манипулятивная техника
8. И снова это "после - значит вследствие" - здесь автор рассказывает, что корреляция совсем не равна причинно-следственной связи. Возможно причина и следствие связаны циклом (как обсуждалось в книге "Искусство системного мышления", про которую я рассказывал раньше) или обе переменных зависят от какой-то другой третьей, а может быть это просто совпадение:)
9. Как производить статикуляции (статистические манипуляции) - тут автор показывает примеры из предыдущих глав и добавляет игры с процентами, повторный учет одних и тех же элементов в расчетах, складывает вместе разные типы объектов и выводит среднее. В общем, поступает очень креативно:)

Продолжение в следующем посте.

#Math #Statistics #PopularScience #Science #Data

ЦЕХ 4 - Урок #6 "Жду музу, а она все не приходит. Эксперт: Лариса Парфентьева"

Продолжая серию постов про свое обучение книгописательству (смотри предыдущие посты: 1, 2, 3, 4 и 5), я расскажу про шестой урок. Он был посвящен поиску вдохновления. Это практическое занятие вела Лариса Парфентьева — автор бестселлеров МИФа с большим количеством регалий.

Занятие было довольно интересным и мне запомнились следующие момены
- Большинство авторов страдают от синжрома самозванца и важно с ним работать
- Сам синдром блокирует нас используя две стратегии: перфекционизм и прокрастинацию
- Насчет перфекционизма важно понимать, что сделать на 100% идеально не получится, поэтому надо быть готовым заделиверить книгу, который ты доволен не на все 100%:)
- А прокрастинацию можно победить используя тайм-менеджмент - надо защищать свое время и пространство, чтобы иметь время сконцентрироваться на творческом процессе и впасть в состояние потока
- Для стимулирования написания свои ощущения можно стимулировать через вкус (пить кофе, есть шоколад и т.д.) во время творческого процесса. Можно ходить на прогулки, чтобы покрутить в голове идеи.
- В общем, надо запланировать время на написание книги и как оно будет распределено в течение дня/недели. Плюс для того, чтобы написать книгу, надо от чего-то отказаться и разгрузить свое расписание:)

#Writing #SelfDevelopment #Management