85 законов
software engineering 85 software
engineering laws

Дал команде две недели на задачу — получишь результат через две недели, независимо от реальной сложности. Объём работы — газ: занимает весь предоставленный объём.

Контрмера: жёсткие короткие итерации, timeboxing, Parkinson-sprints (1–3 дня). Длинные дедлайны — это разрешение на gold-plating, bikeshedding и feature creep.

Give a team two weeks for a task — you get the result in two weeks, regardless of actual complexity. Work behaves like gas: it expands to fill all available volume.

Countermeasure: tight short iterations, timeboxing, Parkinson-sprints (1–3 days). Long deadlines are permission for gold-plating, bikeshedding, and feature creep.

Онбординг новых инженеров требует времени старых. Коммуникационные связи растут как O(N²) — для команды из N человек число каналов равно N(N-1)/2.

Классика: «дадим проекту ещё трёх джунов — успеем к дедлайну» → опоздаешь ещё на месяц. Контрмера: дробить архитектуру на независимые модули до найма, а не после. Inverse Conway.

Onboarding new engineers requires time from the existing ones. Communication channels grow as O(N²) — for a team of N people, the number of channels is N(N-1)/2.

Classic: «let's add three more juniors and hit the deadline» → you'll slip by another month. Countermeasure: partition architecture into independent modules before hiring, not after. Inverse Conway.

Четыре команды напишут четырёхмодульный компилятор. Если у тебя один монолитный тимлид — получишь монолит, как ни старайся.

Inverse Conway Maneuver: сначала проектируй целевую архитектуру, потом под неё формируй команды. Микросервисы требуют автономных команд; монолит — централизованной координации. Несоответствие убивает оба варианта.

Four teams will write a four-pass compiler. If you have one monolithic team lead — you get a monolith, no matter how hard you try.

Inverse Conway Maneuver: design the target architecture first, then form teams to match. Microservices require autonomous teams; monolith requires central coordination. Mismatch kills both.

Люди охотнее исправляют, чем отвечают с нуля. Корректировка — низкие когнитивные затраты, генерация — высокие.

Применение: в код-ревью публикуй draft-решение, а не вопрос «как лучше сделать?». В тикете — сразу гипотеза, а не пустой вопрос. Работает и с LLM: дай плохое решение и попроси раскритиковать — получишь глубже, чем на открытый вопрос.

People are quicker to correct than to answer from scratch. Correction is low cognitive cost; generation is high.

Application: in code review, post a draft solution, not «how should we do this?». In issues — a hypothesis first, not an empty question. Works with LLMs too: give a bad solution and ask for critique — you get deeper output than from an open question.

Feature creep как термодинамический закон. Любая успешная утилита превращается в платформу. Slack начинался как чат для геймеров, теперь — IDE-платформа. Notion начинался как редактор заметок, теперь — БД, wiki, project tracker.

Контрмера: явные non-goals в README/ADR. «Эта система НЕ делает X» — такая же важная декларация, как «делает Y». Защищает архитектуру от давления стейкхолдеров.

Feature creep as a thermodynamic law. Every successful utility becomes a platform. Slack started as gamer chat, now it's an IDE platform. Notion started as a notes editor, now it's DB, wiki, project tracker.

Countermeasure: explicit non-goals in README/ADR. «This system does NOT do X» is as important a declaration as «does Y». Shields architecture from stakeholder pressure.

Знаменитый xkcd про spacebar heating. Ты фиксишь «undefined behavior» — ломаешь трёх клиентов в проде. Документированный контракт — это нижняя граница; реальный контракт — вся surface поведения.

Latency-распределение, порядок полей в JSON, время ответа на ping, формат сообщений в логах — всё уже контракт. Контрмера: property-based testing, chaos engineering, версионирование API с дня 1.

The famous xkcd about spacebar heating. You fix «undefined behavior» — and break three clients in production. The documented contract is the lower bound; the real contract is the entire behavioral surface.

Latency distribution, JSON field order, ping response time, log message format — all already contracts. Countermeasure: property-based testing, chaos engineering, API versioning from day 1.

Команда из 100 → реальную работу тянут ~10. Команда из 10 000 → ~100. Вытекает из power law распределения продуктивности.

Следствие: найм 10x-инженеров даёт нелинейный прирост, найм средних — линейные расходы. Приоритет — несколько ключевых людей, а не «больше рук».

A team of 100 → real work is done by ~10. Team of 10,000 → ~100. Derives from power law productivity distribution.

Implication: hiring 10x engineers gives non-linear gains; hiring average engineers gives linear costs. Prioritize a few key people over «more hands».

Social loafing + координационные потери. Два разработчика пишут не в 2 раза быстрее одного, а в 1.5. Десять — может быть, в 3–4 раза.

Отсюда правило Безоса про «2 pizza teams». Лучше 4 команды по 3 человека, чем одна команда из 12.

Social loafing + coordination overhead. Two developers don't ship 2x faster than one — they ship 1.5x. Ten people, maybe 3–4x.

Hence Bezos's «2 pizza teams» rule. Four teams of three beat one team of twelve.

Измеряешь KPI по закрытым тикетам — получишь микро-тикеты. Измеряешь code coverage — получишь тесты-пустышки на геттеры. Velocity в sprint points → раздутые оценки.

Особенно опасно в ML: метрика loss на train set → overfitting. Контрмера: множественные ортогональные метрики + качественный review. Метрика всегда — прокси, не цель.

Measure KPI by closed tickets — you get micro-tickets. Measure code coverage — you get empty tests on getters. Velocity in sprint points → inflated estimates.

Especially dangerous in ML: train-set loss as a metric → overfitting. Countermeasure: multiple orthogonal metrics + qualitative review. A metric is always a proxy, never the goal.

Антидот к «это нельзя измерить, поэтому не будем пытаться». Morale, code quality, tech debt — можно мерить косвенно (survey, incident rate, lead time).

Плохая метрика > никакой метрики, пока помнишь про закон Гудхарта. DORA metrics — канонический пример разумного применения: deployment frequency, lead time, change failure rate, MTTR.

Antidote to «this can't be measured, so let's not try». Morale, code quality, tech debt — all can be measured indirectly (survey, incident rate, lead time).

A bad metric > no metric, as long as you remember Goodhart's Law. DORA metrics are the canonical example of reasonable application: deployment frequency, lead time, change failure rate, MTTR.

Основа defensive programming и distributed systems design. Network partitions случатся. Диск заполнится. Клиент пошлёт null в required поле.

В системах с высокой доступностью особенно: race condition, который «не может случиться», случится в production в пятницу в 17:59. Контрмера: chaos engineering, assume failure, fail-fast + graceful degradation, идемпотентность.

Foundation of defensive programming and distributed systems design. Network partitions happen. Disks fill up. Clients send null in required fields.

In high-availability systems especially: the race condition that «can't happen» will hit production on Friday at 17:59. Countermeasure: chaos engineering, assume failure, fail-fast + graceful degradation, idempotency.

Рекурсивный. Планирование проектов — NP-hard задача в условиях неполной информации.

Эмпирическое правило: бери оценку, умножай на π (≈3.14). Для research-задач — на 2π. Контрмера: reference-class forecasting — смотри на похожие прошлые проекты, а не строй план с нуля.

Recursive. Project planning is NP-hard under incomplete information.

Empirical rule: take your estimate, multiply by π (≈3.14). For research tasks — by 2π. Countermeasure: reference-class forecasting — look at similar past projects rather than planning from scratch.

Оригинально про научную фантастику, применимо ко всему: коду, библиотекам, стартапам, docs, Stack Overflow ответам.

Следствие: не тратить энергию на критику 90% — искать и учиться у 10%. При выборе OSS-библиотеки предполагай, что она в 90%, пока не доказано обратное (stars, maintainers, issue response time, тесты, последний коммит).

Originally about science fiction; applies to everything: code, libraries, startups, docs, Stack Overflow answers.

Implication: don't waste energy critiquing the 90% — find and learn from the 10%. When choosing an OSS library, assume it's in the 90% until proven otherwise (stars, maintainers, issue response time, tests, recent commits).

Чем дольше технология/идея/практика существует — тем дольше она, вероятно, проживёт ещё. Применимо к не-стареющим (non-perishable) сущностям: коду, идеям, протоколам. Не применимо к биологии.

Unix живёт 55 лет → вероятно, проживёт ещё 55. SQL — 50+. TCP/IP — 40+. Хайповый фреймворк, вышедший в прошлом году → медианная ожидаемая жизнь ~1 год.

Прямое следствие для выбора стека в долгоживущих проектах: предпочитай скучный, проверенный временем стек на критичном пути; новизна — на периферии, где замена дёшева.

The longer a technology/idea/practice has existed, the longer it will likely persist. Applies to non-perishable entities: code, ideas, protocols. Does not apply to biology.

Unix has lived 55 years → likely to last another 55. SQL — 50+. TCP/IP — 40+. The hype framework released last year → median expected life ~1 year.

Direct implication for stack selection in long-lived projects: prefer boring, time-tested stack on the critical path; novelty belongs on the periphery, where replacement is cheap.

Robustness Principle. Сформулирован Джоном Постелом в RFC 761 (TCP). Твой выход — строго по спеке, минимально. Твой вход — толерантен к мелким отклонениям, если intent понятен. Так выживает интернет, где разные реализации одного протокола встречаются и должны договориться.

Тёмная сторона (Thomson & Schinazi, 2023): чрезмерная толерантность на входе превращает баги в de facto стандарт — закон Хайрама вступает в действие. Современная контрпрактика: strict parsing, fail-fast на невалидном вводе, явный протокол версионирования. На критичных стыках — Постел; на эволюционирующих API — строгость.

Robustness Principle. Formulated by Jon Postel in RFC 761 (TCP). Your output — strict to spec, minimal. Your input — tolerant of small deviations, as long as intent is clear. That's how the internet survives, where different implementations of the same protocol meet and must agree.

The dark side (Thomson & Schinazi, 2023): excessive tolerance on input turns bugs into de facto standards — Hyrum's Law kicks in. Modern counter-practice: strict parsing, fail-fast on invalid input, explicit protocol versioning. Postel's stance at critical seams; strict at evolving APIs.

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

Explore: много дешёвых экспериментов, толерантность к провалу, TDD и code review мешают; ценность — скорость гипотез.
Expand: неожиданный успех ломает узкие места; ценность — устранение бутылочных горлышек по одному.
Extract: playbook известен, оптимизация маржи; ценность — надёжность, эффективность, прогнозируемость.

Главная ошибка: навязать Extract-процессы (KPI, code coverage, change advisory boards) команде в Explore-фазе. Метрики бессмысленны, когда сами не знаешь, что измерять.

Beck, after a decade at Facebook, observed: products go through three qualitatively different phases, and most organizational dysfunction stems from applying one phase's discipline to another phase's conditions.

Explore: many cheap experiments, failure tolerance, TDD and code review get in the way; value = hypothesis throughput.
Expand: unexpected success breaks bottlenecks; value = removing them one by one.
Extract: playbook known, margin optimization; value = reliability, efficiency, predictability.

The cardinal error: imposing Extract-processes (KPIs, code coverage, change advisory boards) on an Explore-phase team. Metrics are meaningless when you don't yet know what to measure.

Пол Фиттс, 1951 год, отчёт по авиации — 11 пунктов «Men Are Better At / Machines Are Better At». Машины: скорость, точность, повторяемость, параллелизм, вычисления. Люди: индукция, suspect-detection, гибкость, импровизация, суждение.

Сегодня список устарел частично (ML делает многое из «MABA»), но как инструмент мышления — жив. Применимо к AI-системам: что отдать LLM (генерация, обзор, классификация по паттерну), что оставить человеку (контекстное суждение, решение в условиях ambiguity, принятие ответственности).

Главная критика Шеридана и Декера: список предполагает, что задачи можно атомарно разделить. На практике задачи переплетены, и распределение часто превращается в «left-over principle» — человеку отдают всё, что машина не смогла, независимо от того, способен ли человек это сделать.

Paul Fitts, 1951, aviation report — 11 statements «Men Are Better At / Machines Are Better At». Machines: speed, precision, repetition, parallelism, computation. Humans: induction, suspect-detection, flexibility, improvisation, judgment.

The list is partially outdated today (ML now does much of the «MABA» side), but as a thinking tool — alive. Applies to AI systems: what to delegate to LLMs (generation, review, pattern classification), what to keep with humans (contextual judgment, decisions under ambiguity, ownership).

The main critique from Sheridan and Dekker: the list assumes tasks can be cleanly partitioned. In practice tasks are interwoven, and allocation often becomes the «left-over principle» — humans get everything the machine couldn't handle, regardless of whether humans can do it.

Прямое возражение списку Фиттса. Замена «горячая» — нельзя автоматизировать функцию X и оставить остальное нетронутым. Автоматизация X меняет:

— что человек видит (меньше прямого контакта с системой);
— что человек знает (деградация навыков, которые не используются);
— как человек реагирует на сбой автоматики (когда она падает, человек уже не в контексте);
— границы ответственности (кто отвечает, когда AI принял решение?).

Это «ironies of automation» Бэйнбридж (1983): чем больше автоматизирован обычный режим, тем критичнее и реже становится участие человека — и тем хуже он подготовлен в момент, когда нужен. Прямо применимо к AI-coding: «AI пишет 90% кода» означает, что когда AI ошибается на оставшихся 10%, инженер уже не в контексте, чтобы поймать ошибку.

A direct rebuttal to Fitts's List. The substitution is «hot» — you can't automate function X and leave the rest untouched. Automating X changes:

— what the human sees (less direct contact with the system);
— what the human knows (skill decay for what's no longer practiced);
— how the human responds to automation failure (when it falls, the human is already out of context);
— accountability boundaries (who owns the decision the AI made?).

This is Bainbridge's «ironies of automation» (1983): the more the normal mode is automated, the rarer and more critical the human's intervention becomes — and the less prepared they are for it. Directly applicable to AI-coding: «AI writes 90% of code» means when AI errs on the remaining 10%, the engineer is already out of context to catch it.

Йенс Расмуссен (1997) описал операционное пространство любой сложной системы тремя границами:

— экономическая граница (банкротство при превышении затрат);
— граница нагрузки (выгорание людей при превышении);
— граница приемлемого качества (катастрофа за ней).

Между ними — операционное пространство. Менеджмент давит от экономической границы внутрь (cut costs). Люди давят от границы нагрузки внутрь (work less). Оба градиента толкают точку к границе катастрофы. Дрейф происходит не одним прыжком, а сериями мелких локальных оптимизаций: каждая по отдельности рациональна, но в сумме они эродируют запас прочности до нуля.

«Going solid» (Cook & Rasmussen, 2005): нормальный буфер вариативности съеден; следующее малое возмущение пробивает границу.

Jens Rasmussen (1997) described the operating space of any complex system through three boundaries:

— economic boundary (bankruptcy beyond it);
— workload boundary (burnout beyond it);
— acceptable performance boundary (catastrophe beyond it).

Between them — the operating space. Management pushes from the economic boundary inward (cut costs). People push from the workload boundary inward (work less). Both gradients drive the operating point toward the catastrophe boundary. Drift happens not in a single jump but in waves of small local optimizations: each individually rational, collectively eroding safety margin to zero.

«Going solid» (Cook & Rasmussen, 2005): the normal variability buffer is consumed; the next small perturbation breaches the boundary.

Дисциплина, возникшая в Netflix (Chaos Monkey, 2010). Принцип: надёжность системы не выводится из спецификации — она проверяется индукцией от реальных сбоев. Mental model — экспериментальная наука: гипотеза («система переживёт убийство одного pod»), эксперимент в проде, проверка steady-state метрик, scoping blast radius.

Четыре правила Principles of Chaos:

1. Определи измеримый steady-state (latency p99, error rate).
2. Сформулируй гипотезу — что останется в норме при возмущении.
3. Введи реальные сбои (kill instance, добавь latency, отключи зону).
4. Если гипотеза опровергнута — найдена слабость до того, как нашёл клиент.

Прямой ответ Расмуссену: chaos engineering — это контролируемое движение точки к границе, чтобы измерить запас, не дожидаясь «going solid». Антипод pre-mortem-планирования: вместо того чтобы воображать, как сломается, ломай и смотри.

A discipline born at Netflix (Chaos Monkey, 2010). Principle: system reliability isn't derived from spec — it's verified by induction from real failures. Mental model — experimental science: hypothesis («the system survives killing one pod»), experiment in production, check steady-state metrics, scope the blast radius.

Four rules of the Principles of Chaos:

1. Define a measurable steady-state (p99 latency, error rate).
2. State the hypothesis — what stays normal under perturbation.
3. Inject real failures (kill instance, add latency, disable zone).
4. If the hypothesis fails — you found weakness before a customer did.

A direct response to Rasmussen: chaos engineering is the controlled push of the operating point toward the boundary to measure the margin, before «going solid» happens for real. The opposite of pre-mortem-only planning: instead of imagining how it breaks, break it and observe.

Подход Тодда Конклина (нач. 2000-х) и линия Декера/Холлнагеля/Расмуссена. Альтернатива «old view of safety» (человек = источник ошибки → больше правил → меньше ошибок). Пять принципов:

1. Ошибка нормальна. Никакой объём тренинга не уберёт ошибки полностью. Цель — не «ноль ошибок», а «ноль катастроф».
2. Обвинение ничего не чинит. Blame ломает feedback loop: люди перестают сообщать о near-miss.
3. Контекст определяет поведение. Не «глупый инженер задеплоил в пятницу», а «процесс не блокировал пятничный деплой».
4. Обучение жизненно важно. Постоянная экстракция уроков из normal work, не только из инцидентов.
5. То, как мы реагируем, имеет значение. Реакция руководства на инцидент калибрует всю организацию — открытость или скрытие.

«Black line / Blue line»: чёрная линия — работа как её представляет планировщик (идеальная процедура); синяя — как реально выполняется (с адаптациями, обходами, локальными решениями). Гэп между ними — обычная вещь, и его сокращение начинается с понимания, почему синяя такая.

Todd Conklin's approach (early 2000s), in the lineage of Dekker / Hollnagel / Rasmussen. An alternative to the «old view of safety» (human = error source → more rules → fewer errors). Five principles:

1. Error is normal. No amount of training removes error fully. The goal isn't «zero errors» but «zero catastrophes».
2. Blame fixes nothing. Blame breaks the feedback loop: people stop reporting near-misses.
3. Context drives behavior. Not «the stupid engineer deployed on Friday», but «the process didn't block Friday deploys».
4. Learning is vital. Continuous extraction of lessons from normal work, not just incidents.
5. How we respond matters. Leadership's response to incidents calibrates the entire organization — openness or concealment.

«Black line / Blue line»: the black line is work as planners imagine it (ideal procedure); the blue line is how it's actually performed (with adaptations, workarounds, local decisions). The gap between them is normal, and closing it starts with understanding why the blue line is what it is.

Дисциплина, оформленная Холлнагелем, Вудсом и Левесон в 2000-х. Безопасность — не то, что система имеет, а то, что она делает. Четыре способности резильентной системы (Hollnagel's Four Cornerstones):

— Respond: реакция на актуальное возмущение, известное или нет;
— Monitor: отслеживание того, что может стать проблемой в ближайшем будущем;
— Anticipate: предвидение долгосрочных угроз и возможностей;
— Learn: извлечение опыта из прошлого, в том числе успехов, не только сбоев.

Ключевое различие с традиционным safety: Safety-I — отсутствие плохого (минимизация ошибок); Safety-II — присутствие хорошего (изучение того, почему 99% работы идёт нормально, не только разбор оставшегося 1%). Резильентность строится на slack, redundancy и adaptive capacity — на способности людей и систем гнуться, не ломаясь, когда реальность отклоняется от спецификации.

Прямое следствие для инженерных команд: on-call rotation, post-incident review, blameless culture, явные кадровые буферы — это не накладные расходы, а инвестиция в резильентность. Систему без slack первый же шок ломает.

A discipline formalized by Hollnagel, Woods, and Leveson in the 2000s. Safety isn't something a system has — it's something it does. Four capabilities of a resilient system (Hollnagel's Four Cornerstones):

— Respond: react to the actual disturbance, known or not;
— Monitor: track what may become a problem in the near term;
— Anticipate: foresee longer-horizon threats and opportunities;
— Learn: extract lessons from the past, including successes — not only failures.

Key distinction vs traditional safety: Safety-I = absence of the bad (minimize errors); Safety-II = presence of the good (study why 99% of work goes right, not only investigate the remaining 1%). Resilience is built on slack, redundancy, and adaptive capacity — on the ability of people and systems to bend without breaking when reality deviates from spec.

Direct implication for engineering teams: on-call rotation, post-incident review, blameless culture, explicit staffing buffers — these aren't overhead, they're investment in resilience. A system without slack snaps at the first shock.

Манни Леман сформулировал 8 законов эволюции (1974–1996). Главные три для практики:

I. Continuing Change: система типа E (та, что встроена в реальный мир) должна меняться, иначе её удовлетворение задач падает. Не «закончил и забыл» — а «либо живёт и эволюционирует, либо умирает».
II. Increasing Complexity: сложность растёт монотонно, если активно не уменьшать. Каждая правка добавляет случайные связи; без рефакторинга энтропия побеждает.
VI. Continuing Growth: функциональность должна расти, чтобы удовлетворить пользователей — но рост сам генерирует сложность (петля с законом II).

Прямое следствие: tech debt — не выбор, а термодинамический налог. Не платишь рефакторингом — платишь тормозом скорости разработки и багами. Связка с Завински (рост фич) и Линди (старые системы — те, что выжили эволюционируя).

Manny Lehman formulated 8 evolution laws (1974–1996). The three most practical:

I. Continuing Change: an E-type system (embedded in the real world) must change, or its fitness for purpose declines. Not «finish and forget» — «evolve or die».
II. Increasing Complexity: complexity grows monotonically unless actively reduced. Every change adds accidental couplings; without refactoring, entropy wins.
VI. Continuing Growth: functionality must grow to keep users satisfied — but growth itself generates complexity (a loop with Law II).

Direct implication: tech debt isn't a choice, it's a thermodynamic tax. Don't pay with refactoring — you pay with slower velocity and bugs. Connects to Zawinski (feature growth) and Lindy (old systems are the ones that evolved successfully).

Сформулировано Питером Дойчем (Sun Microsystems, 1994), позже расширено Джеймсом Гослингом. Применимо ко всему, что не на одном процессе на одной машине — от микросервисов до браузера, общающегося с API.

Восемь заблуждений:

1. Сеть надёжна. Пакеты теряются, соединения рвутся.
2. Latency = 0. Каждый hop стоит миллисекунды; для HFT — микросекунды.
3. Bandwidth бесконечна. Большие payloads + many calls = bottleneck.
4. Сеть безопасна. mTLS, auth, encryption — не optional.
5. Топология не меняется. Поды рестартуют, IP меняются, ноды падают.
6. Есть один администратор. Команды команд, разные ownership, разные SLA.
7. Transport cost = 0. Сериализация, парсинг, network IO — всё дорого.
8. Сеть гомогенна. Разные клиенты, разные версии, разные протоколы.

Прямое продолжение Мёрфи и предтеча CAP. Каждое заблуждение опровергнуто конкретным production-инцидентом в каждой крупной компании.

Formulated by Peter Deutsch (Sun Microsystems, 1994), later extended by James Gosling. Applies to anything beyond a single process on a single machine — from microservices to a browser talking to an API.

The eight fallacies:

1. The network is reliable. Packets drop, connections break.
2. Latency is zero. Each hop costs milliseconds; HFT — microseconds.
3. Bandwidth is infinite. Large payloads + many calls = bottleneck.
4. The network is secure. mTLS, auth, encryption — not optional.
5. Topology doesn't change. Pods restart, IPs change, nodes die.
6. There is one administrator. Teams of teams, different ownership, different SLAs.
7. Transport cost is zero. Serialization, parsing, network IO — all expensive.
8. The network is homogeneous. Different clients, different versions, different protocols.

A direct extension of Murphy and precursor to CAP. Every fallacy is refuted by a specific production incident at every major company.

Джеймс Ризон (1990) — модель аккумулирующейся уязвимости. Каждый слой защиты (code review, unit tests, integration tests, staging, canary, monitoring) — это срез сыра с дырами. Дыры — это latent failures: мелкие пробелы, которые сами по себе не катастрофичны.

Большинство атак / багов / инцидентов блокируются хотя бы одним слоем. Катастрофа происходит, когда конкретный сценарий попадает в дыру первого слоя, потом второго, и так до проникновения сквозь все. Это не «единственная причина» — это совпадение нескольких ослабленных условий.

Два типа дыр:

— Active failures — действия людей на острие (опечатка в команде, неверный merge), быстро видны.
— Latent conditions — структурные дефекты системы (плохое логирование, отсутствие алерта, runbook устарел), часто скрыты годами.

Прямое практическое следствие: после инцидента ищи не «виновного» (active failure), а латентные условия, которые позволили активной ошибке пройти. Связка с HOP — blame fixes nothing — потому что blame не закрывает дыры в латентных слоях.

James Reason (1990) — a model of accumulated vulnerability. Each defense layer (code review, unit tests, integration tests, staging, canary, monitoring) is a slice of cheese with holes. The holes are latent failures: small gaps, individually non-catastrophic.

Most attacks / bugs / incidents are blocked by at least one layer. A catastrophe happens when a specific scenario falls through the hole in the first layer, then the second, and so on through all of them. This is not «a single cause» — it's the coincidence of several weakened conditions.

Two types of holes:

— Active failures — sharp-end human actions (a command typo, a wrong merge), quickly visible.
— Latent conditions — structural defects in the system (poor logging, missing alert, stale runbook), often hidden for years.

Direct practical implication: after an incident, don't hunt for «the guilty» (active failure) — hunt for latent conditions that let the active error through. Ties to HOP — blame fixes nothing — because blame doesn't close holes in latent layers.

Эрик Брюер, 2000. Формально доказано Gilbert & Lynch, 2002. Три свойства:

— Consistency: каждый read видит самую свежую запись (или ошибку).
— Availability: каждый запрос получает не-ошибочный ответ.
— Partition tolerance: система продолжает работать при разрыве сети между узлами.

Уточнение, которое часто пропускают: в реальной сети partitions неизбежны (см. fallacy #1). Значит, P — не выбор, а данность. Реальный trade-off — между C и A в момент партиции:

CP-системы (etcd, ZooKeeper, traditional RDBMS с strong consistency): при партиции отказывают в обслуживании, чтобы не отдать stale данные. Используются для конфигурации, координации, leader election.
AP-системы (Cassandra, DynamoDB, DNS): при партиции продолжают отвечать, принимая риск рассинхронизации, чинят eventual consistency. Используются для шопинг-корзин, лент, метрик.

PACELC (Abadi, 2012) — расширение: в случае Partition выбирай A или C; иначе (Else) выбирай Latency или Consistency. Это и есть реальный ландшафт решений.

Eric Brewer, 2000. Formally proven by Gilbert & Lynch, 2002. Three properties:

— Consistency: every read sees the latest write (or an error).
— Availability: every request receives a non-error response.
— Partition tolerance: the system keeps working under network splits between nodes.

The often-missed clarification: in a real network, partitions are inevitable (see fallacy #1). So P isn't a choice, it's a given. The real trade-off is between C and A during the partition:

CP systems (etcd, ZooKeeper, traditional RDBMS with strong consistency): refuse service during a partition to avoid returning stale data. Used for configuration, coordination, leader election.
AP systems (Cassandra, DynamoDB, DNS): keep responding during a partition, accepting the risk of divergence, repair via eventual consistency. Used for shopping carts, feeds, metrics.

PACELC (Abadi, 2012) extends this: during a Partition pick A or C; Else (no partition) pick Latency or Consistency. That's the real decision landscape.

Фред Брукс, The Mythical Man-Month, глава 1. Тот же Брукс, что в секции 2 — но другой угол. Четырёхквадрантная модель: одиночная программа, написанная одним человеком, проходит через два независимых перехода, каждый умножает стоимость на ~3.

Горизонтальный переход (×3) — Programming Systems / Программный комплекс:

Программа становится частью системы взаимодействующих компонентов. Что добавляется:
— точно определённые интерфейсы (контракты, версионирование);
— бюджет ресурсов (память, CPU, IO — нельзя «занять всё»);
— интеграционное тестирование во всех комбинациях (комбинаторный взрыв сценариев).

Вертикальный переход (×3) — Programming Product / Программный продукт:

Программа становится продуктом, которым может пользоваться кто-то кроме автора. Что добавляется:
— обобщение (работает на разных входах, не только на «моих»);
— тестирование (unit / integration / regression);
— документация (как читать, как использовать, как чинить);
— сопровождение (bug fixes, версии, deprecation).

Угол по диагонали — Systems Product / Системный программный продукт:

Оба перехода применены. Стоимость: ×3 × ×3 = ×9 от исходной программы. Это и есть то, что 90% инженерных проектов реально хотят построить, но оценивают как программу.

Прямые следствия для оценки сроков:

1. Прототип «работает у меня» — это верхний левый квадрант. До production-grade остаётся ×9 работы.
2. AI-сгенерированный код по умолчанию в верхнем левом квадранте. «AI написал решение за 10 минут» означает, что до интеграции и продукта остаётся ~90 минут эквивалентной работы.
3. Закон Хофштадтера (sect.12) о коэффициенте π в оценках — частично объясняется именно этой моделью: люди оценивают программу, а строят системный продукт.
4. Закон Завински (sect.5) — это давление перехода «программа → комплекс» от пользователей, которые хотят, чтобы их программа «читала почту».

Fred Brooks, The Mythical Man-Month, chapter 1. Same Brooks as in section 2 — different angle. A four-quadrant model: a standalone program written by one person goes through two independent transitions, each multiplying cost by ~3.

Horizontal transition (×3) — Programming System:

The program becomes part of a system of interacting components. What gets added:
— precisely defined interfaces (contracts, versioning);
— resource budget (memory, CPU, IO — can no longer «consume everything»);
— integration testing across all combinations (combinatorial explosion of scenarios).

Vertical transition (×3) — Programming Product:

The program becomes a product usable by someone other than the author. What gets added:
— generalization (works on varied inputs, not just «mine»);
— testing (unit / integration / regression);
— documentation (how to read, use, fix);
— maintenance (bug fixes, versions, deprecation).

Diagonal corner — Programming Systems Product:

Both transitions applied. Cost: ×3 × ×3 = ×9 of the original program. This is what 90% of engineering projects actually want to build, but estimate as a program.

Direct implications for estimation:

1. A prototype that «works on my machine» is the upper-left quadrant. ×9 work remains to reach production.
2. AI-generated code lives, by default, in the upper-left quadrant. «AI wrote the solution in 10 minutes» means ~90 minutes of equivalent work remains until integration and product.
3. Hofstadter's Law (sect.12) on the π factor — partially explained by this model: people estimate a program, then build a systems product.
4. Zawinski's Law (sect.5) — that's the pressure of the «program → system» transition coming from users who want their program to «read mail».

Фред Брукс, 1986. Самая цитируемая статья после Mythical Man-Month. Различение двух типов сложности:

Essential complexity — присуща самой задаче. Бизнес-домен сложен. Требования противоречивы. Состояний много. Concurrency реальна. Этого нельзя «убрать» технологией — только понять и смоделировать.

Accidental complexity — введена нашими инструментами. Сборка проекта, синтаксис языка, ручное управление памятью, boilerplate, конфигурация CI/CD. Это можно убирать — и за последние 50 лет мы убирали успешно: ассемблер → высокоуровневые языки, malloc → garbage collection, мейкфайлы → bundlers, FTP → git.

Тезис Брукса: доля accidental complexity уже мала, и каждое новое поколение инструментов даёт всё меньший прирост. Чтобы было «×10 продуктивности», нужно атаковать essential — а её не атакуют технологии, её атакует мышление.

Прямое следствие для AI-эры (2026): «AI ускорит разработку в 10×» — попытка применить silver bullet к essential complexity. AI снижает accidental (boilerplate, lookup, рутинный синтаксис, draft-тесты), но essential — понимание домена, выбор trade-offs, проектирование контрактов между системами — остаётся за человеком. Поэтому AI меняет распределение работы внутри инженера, но не убирает её совокупный объём.

Связка с Lehman (sect.23): essential complexity растёт вместе с эволюцией системы. Связка с Hofstadter (sect.12): люди оценивают по accidental (быстро вижу, как сделать), а делают essential (которую не видно из оценки).

Fred Brooks, 1986. The most cited paper after Mythical Man-Month. A distinction between two types of complexity:

Essential complexity — inherent to the problem. Business domain is complex. Requirements are contradictory. State spaces are large. Concurrency is real. You can't «remove» this with a tool — only model and understand it.

Accidental complexity — introduced by our tooling. Build systems, language syntax, manual memory management, boilerplate, CI/CD config. This can be removed — and we've been removing it for 50 years: assembly → high-level languages, malloc → garbage collection, makefiles → bundlers, FTP → git.

Brooks's thesis: the share of accidental complexity is already small, and each new generation of tools delivers diminishing gains. To get a «×10 productivity» you'd need to attack essential complexity — and that's not attacked by technology, it's attacked by thinking.

Direct implication for the AI era (2026): «AI will speed up development by 10×» is an attempt to apply silver-bullet logic to essential complexity. AI reduces accidental (boilerplate, lookup, routine syntax, draft tests), but essential — understanding the domain, choosing trade-offs, designing contracts between systems — stays with the human. Therefore AI changes the distribution of work inside the engineer's day, but doesn't reduce its total volume.

Ties to Lehman (sect.23): essential complexity grows with system evolution. Ties to Hofstadter (sect.12): people estimate based on accidental (I see how to do it fast), but build essential (which isn't visible at estimation time).

Брукс, MMM, глава 5. Психологический паттерн, повторяющийся в карьере инженеров:

Первая система — minimum viable. Инженер не знает, что возможно, боится неизвестности, делает консервативно. Получается работающая, скромная, иногда даже элегантная система.

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

Третья и последующие системы — взвешенные. Инженер уже видел провал второй и научился отделять реальную сложность от воображаемой.

Канонические примеры: OS/360 (катастрофа IBM, заставившая Брукса написать MMM), Netscape 6 (потеря рынка), Perl 6 / Raku (15+ лет разработки), множество «v2» продуктов и стартапов после exit.

Связка с Завински (sect.5): Завински — про внешнее давление feature creep от пользователей. Second-system — про внутреннее давление инженерного эго. Оба ведут к одному месту, но через разные механизмы. Защита разная: против Завински — non-goals в README; против second-system — внешняя дисциплина (более опытный архитектор, ревью извне команды, явный scope cap).

В контексте AI-augmented coding: AI снижает стоимость экспериментов, и поэтому может усилить second-system effect — «давай я сделаю это правильнее с пятью уровнями абстракции, AI же напишет». Контрмера: применяй те же фильтры YAGNI и осознанной non-generalization, что и без AI.

Brooks, MMM, chapter 5. A psychological pattern that recurs across engineering careers:

First system — minimum viable. The engineer doesn't yet know what's possible, fears the unknown, builds conservatively. The result is a working, modest, sometimes even elegant system.

Second system — the trap. The engineer now «knows how it should be done». Accumulating:
— features «we should have added to the first one but didn't have time»;
— generalizations «for every case» (frameworks, plugin systems, configurability);
— refactorings the first system was too risky for;
— «correct» abstractions you had no experience to build before.

Third and later systems — calibrated. The engineer has seen the second one fail and learned to separate real complexity from imagined.

Canonical examples: OS/360 (IBM's catastrophe that drove Brooks to write MMM), Netscape 6 (loss of market), Perl 6 / Raku (15+ years in development), countless «v2» products and post-exit startups.

Ties to Zawinski (sect.5): Zawinski is about external feature-creep pressure from users. Second-system is about internal pressure from engineering ego. Both end up at the same place via different mechanisms. Different defenses: against Zawinski — non-goals in README; against second-system — external discipline (more senior architect, cross-team review, explicit scope cap).

In the context of AI-augmented coding: AI lowers the cost of experiments, and can amplify the second-system effect — «let me do it properly with five abstraction layers, AI will write it anyway». Counter: apply the same YAGNI and deliberate non-generalization filters as without AI.

Брукс, MMM, глава 4. Канонический тезис: «Архитектура — это работа одного ума, или малой группы единомышленников». Из этого следует жёсткое разделение архитектуры и реализации.

Что такое концептуальная целостность: в системе с конц. целостностью пользователь / разработчик может предсказать, как поведёт себя ещё не виденная им часть системы — просто потому, что знает остальные части. Везде одни и те же conventions, одни и те же mental models, одни и те же trade-offs.

Примеры систем с высокой конц. целостностью: Unix philosophy (всё файл, программы делают одно дело хорошо), Smalltalk (всё объект), Erlang (всё actor с message passing), Lisp (всё s-expression). Их можно не любить, но их легко понять, потому что понимая 10% — понимаешь, чего ожидать от остальных 90%.

Примеры систем с низкой целостностью: C++ (parts по разным эпохам и философиям), PHP (исторические наслоения), большинство enterprise-монолитов после нескольких смен команд.

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

Связки с другими законами:

— Закон Конвея (sect.3): Conway про то, как топология команды отображается в архитектуру. Brooks про то, что должно быть в архитектуре, чтобы она была хорошей. Прямое следствие: если хочешь конц. целостность — нужна малая, согласованная архитектурная группа, а не комитет.
— Закон Завински (sect.5) и Second-System (sect.29): оба давят на целостность. Защита от обоих — явный отказ от фич, не подходящих философии.
— 3X Бека (sect.16): на фазе Explore целостность не нужна (всё равно выкинешь); на Extract — критична, потому что система живёт долго и читается многими.

Brooks, MMM, chapter 4. The canonical thesis: «Architecture must come from one mind, or from a very small group of agreeing minds». Implies a hard separation of architecture from implementation.

What conceptual integrity is: in a system with conceptual integrity, the user / developer can predict how an unseen part of the system will behave — purely because they know the other parts. Same conventions everywhere, same mental models, same trade-offs.

Examples of high conceptual integrity: Unix philosophy (everything is a file, programs do one thing well), Smalltalk (everything is an object), Erlang (everything is an actor with message passing), Lisp (everything is an s-expression). You can dislike them, but they're easy to understand because knowing 10% tells you what to expect from the other 90%.

Examples of low integrity: C++ (parts from different eras and philosophies), PHP (historical layers), most enterprise monoliths after several team turnovers.

The cost: achieving conceptual integrity requires an «architecture dictator» — an architect or small group that rejects good ideas that don't fit the philosophy. Most «functionally useful» suggestions will be turned down — not because they're bad, but because they break integrity.

Ties to other laws:

— Conway's Law (sect.3): Conway is about how team topology maps onto architecture. Brooks is about what should be in the architecture for it to be good. Direct implication: if you want conceptual integrity — you need a small, agreeing architectural group, not a committee.
— Zawinski (sect.5) and Second-System (sect.29): both press on integrity. The defense against both is the explicit rejection of features that don't fit the philosophy.
— Beck's 3X (sect.16): in Explore phase integrity isn't needed (you'll throw it away anyway); in Extract — it's critical, because the system lives long and is read by many.

Джеффри Мур, Crossing the Chasm, 1991. Технологический жизненный цикл (адаптация модели Роджерса 1962): innovators → early adopters → early majority → late majority → laggards. Главное наблюдение Мура: между вторым и третьим сегментом — не плавный переход, а пропасть.

Что покупают ранние последователи (early adopters / визионеры):

— потенциал и видение;
— конкурентное преимущество через ранний шаг;
— готовы терпеть незавершённость продукта и активно дорабатывать его сами;
— покупают у незнакомого вендора по референсам отдельных людей.

Что покупает раннее большинство (early majority / прагматики):

— законченный whole product (см. sect.32);
— социальное доказательство от других прагматиков, не от визионеров;
— стандартный stack, не bleeding edge;
— покупают у вендора с положительной репутацией в их индустрии.

Почему пропасть: референсы визионеров бесполезны для прагматиков — они вообще не считают визионеров «такими как мы». Прагматики ждут, пока другие прагматики в их индустрии перейдут — а те ждут того же. Возникает chicken-and-egg, который большинство технологий не проходят.

Симптомы того, что ты в chasm: у тебя есть несколько любящих пилотных клиентов; они дают восторженные отзывы; новые лиды останавливаются на стадии evaluation; роста воронки нет, хотя продукт «работает».

Engineering-следствия:

1. Архитектура для ранних последователей ≠ архитектура для раннего большинства. Визионеры терпят кастомизацию под каждого; прагматики требуют конфигурируемого whole product.
2. Это **не «доделаем фичи и продастся»**. Это переход в другой режим разработки: документация, support, integrations, security audits, compliance.
3. Прямая связка с 3X Бека (sect.16): фаза Expand начинается **только после** успешного chasm crossing. До этого ты ещё в Explore, как бы ни казалось обратное.

Geoffrey Moore, Crossing the Chasm, 1991. The technology adoption lifecycle (adapted from Rogers, 1962): innovators → early adopters → early majority → late majority → laggards. Moore's central observation: between the second and third segments there's not a smooth transition but a chasm.

What early adopters (visionaries) buy:

— potential and vision;
— competitive advantage from being early;
— willing to tolerate an unfinished product and actively co-build it;
— buy from unknown vendors on individual personal referrals.

What early majority (pragmatists) buy:

— a finished whole product (see sect.32);
— social proof from other pragmatists, not from visionaries;
— standard stack, not bleeding edge;
— buy from vendors with established reputation in their industry.

Why a chasm: visionary referrals are useless to pragmatists — they don't consider visionaries «people like us». Pragmatists wait for other pragmatists in their industry to switch — and those are waiting for the same. A chicken-and-egg emerges that most technologies don't cross.

Signs you're in the chasm: you have a few enthusiastic pilot customers; their feedback is glowing; new leads stall at evaluation; pipeline isn't growing even though the product «works».

Engineering implications:

1. Architecture for early adopters ≠ architecture for early majority. Visionaries tolerate custom work per client; pragmatists require a configurable whole product.
2. This is **not «finish features and it will sell»**. It's a shift into a different development mode: documentation, support, integrations, security audits, compliance.
3. Direct tie to Beck's 3X (sect.16): the Expand phase begins **only after** a successful chasm crossing. Before that you're still in Explore, however much it looks otherwise.

Мур (адаптировал концепт Теодора Левитта). Любой продукт существует в четырёх концентрических слоях, и каждый сегмент рынка требует своего радиуса.

Generic Product — то, что ты собственно построил и продаёшь. Core feature, MVP. То, что покупает innovator.

Expected Product — минимум, который покупатель ожидает увидеть, чтобы продукт был «настоящим». Базовая документация, простой UI, оплата и поддержка. То, что нужно visionary.

Augmented Product — то, что даёт ценность реально: integrations с уже существующим стеком клиента, training, deployment helpers, success stories, compliance, security audit, SLA. То, что требуют прагматики.

Potential Product — то, чем продукт может стать через ecosystem: third-party plugins, certified partners, marketplace. То, что превращает продукт в платформу.

Прямая связка с ×9 Бруксом (sect.27): ×9 — это масштаб затрат на переход от program к systems product. Whole Product — это состав того, что добавляется. Два угла на один феномен:

— Brooks: «cost умножается на ×9»
— Moore: «вот конкретно, на что эти ×9 тратятся, и кому нужен каждый слой»

Engineering-следствия:

1. Roadmap должен быть слоистым, а не feature-list. Не «добавим фичу X, потом Y», а «закроем expected level для текущего сегмента, потом augmented для следующего».
2. Большая часть инвестиций в whole product — не «фичи»: это документация, deployment templates, terraform modules, SDK, integrations, compliance docs. Инженеры часто их недооценивают как «не настоящая работа».
3. «Чужой» слой надо строить даже если ты уверен, что у клиента он есть. Pragmatist хочет, чтобы поставщик отвечал за whole product, а не складывал из 5 разных вендоров.

Moore (adapted from Theodore Levitt's concept). Every product exists in four concentric layers, and each market segment demands a different radius.

Generic Product — what you actually built and sell. Core feature, MVP. What innovators buy.

Expected Product — the minimum the buyer expects to see for the product to feel «real». Basic docs, simple UI, payment, support. What visionaries need.

Augmented Product — what delivers real value: integrations with the customer's existing stack, training, deployment helpers, success stories, compliance, security audits, SLA. What pragmatists demand.

Potential Product — what the product can become through ecosystem: third-party plugins, certified partners, marketplace. What turns the product into a platform.

Direct tie to Brooks's ×9 (sect.27): ×9 is the magnitude of cost in the program → systems-product transition. Whole Product is the composition of what's added. Two angles on one phenomenon:

— Brooks: «cost multiplies by ×9»
— Moore: «here's specifically what those ×9 are spent on, and who needs each layer»

Engineering implications:

1. Roadmap should be layered, not feature-listed. Not «add feature X, then Y», but «close expected level for current segment, then augmented for the next».
2. Most whole-product investment isn't «features»: docs, deployment templates, terraform modules, SDKs, integrations, compliance docs. Engineers often dismiss these as «not real work».
3. Build «someone else's» layer even when you're sure the customer has it. Pragmatists want a single vendor accountable for the whole product, not five vendors stacked.

Мур, развитая D-Day метафора: чтобы взять Европу, союзники не высаживались тонким слоем по всему побережью — они сконцентрировали всю мощь на Нормандии, закрепились, потом расширились. Так же с рынком.

Признаки правильного beachhead-сегмента:

1. Достаточно узкий, чтобы ты мог построить whole product (sect.32) для него с твоими текущими ресурсами;
2. Достаточно большой, чтобы давать survival-выручку и social proof;
3. У игроков сегмента есть compelling reason to buy — острая боль, не «было бы хорошо»;
4. Игроки сегмента общаются между собой — есть word-of-mouth внутри;
5. Есть путь от этого сегмента к соседнему (bowling pin → next pin).

Канонический антипаттерн: «наш продукт может всё, мы продаём всем, у кого есть проблема X». В результате whole product недостроен ни для кого, референсы не накапливаются, chasm не преодолевается. Распыление выглядит как демократизация, а является провалом фокуса.

Связки с другими законами:

— Second-System (sect.29): beachhead — это product-level защита от того же феномена. «Не делаем поддержку всех вертикалей, не делаем мульти-tenancy, не делаем интернационализацию — мы пока в одной нише.»
— 3X Бека (sect.16): в фазе Explore beachhead помогает сфокусировать эксперименты. В Expand — это литерално тот рынок, который ты захватываешь.
— Завински (sect.5): beachhead даёт критерий, какие feature-requests принимать. «Это нужно для текущего сегмента?» — да → план; нет → backlog или отказ.
— Conceptual Integrity (sect.30): сфокусированный сегмент позволяет сохранить целостность дизайна. Универсальный продукт почти всегда теряет философию.

Практический тест: если ты не можешь назвать конкретного человека по имени, у которого конкретная боль, которую ты лечишь конкретным образом за следующие 90 дней — у тебя нет beachhead, у тебя есть idea cloud.

Moore's extended D-Day metaphor: to take Europe, the Allies didn't land thinly along the whole coast — they concentrated full force on Normandy, established a foothold, then expanded. Same with markets.

Signs of a good beachhead segment:

1. Narrow enough that you can build the whole product (sect.32) for it with your current resources;
2. Large enough to give you survival revenue and social proof;
3. The players in the segment have a compelling reason to buy — sharp pain, not «would be nice»;
4. The players talk to each other — word-of-mouth exists inside;
5. A path leads from this segment to the next (bowling pin → next pin).

Canonical anti-pattern: «our product does everything, we sell to anyone with problem X». Result: whole product is built for no one, references don't accumulate, chasm isn't crossed. Spread looks like democratization, behaves like failure of focus.

Ties to other laws:

— Second-System (sect.29): beachhead is the product-level defense against the same phenomenon. «No multi-vertical support, no multi-tenancy, no i18n — we're in one niche for now.»
— Beck's 3X (sect.16): in Explore, beachhead focuses experiments. In Expand, it's literally the market you're conquering.
— Zawinski (sect.5): beachhead provides the criterion for which feature requests to accept. «Is it needed for the current segment?» — yes → roadmap; no → backlog or decline.
— Conceptual Integrity (sect.30): a focused segment lets you preserve design coherence. A universal product almost always loses philosophy.

Practical test: if you can't name a specific person with a specific pain you solve in a specific way over the next 90 days — you don't have a beachhead, you have an idea cloud.

Сформулированы Робертом Мартином в 2000-х, аббревиатура Майкла Фезерса. Каждый принцип имеет предсказательную силу: его нарушение порождает конкретный класс проблем при изменении кода.

S — Single Responsibility Principle. У класса должна быть одна причина для изменения. Канонически: «класс должен быть ответственен перед одним актором». Если описание класса требует слова «и» — это два класса, склеенных в один. Нарушение → каждое изменение в одной области ломает несвязанное.

O — Open/Closed Principle. Сущности открыты для расширения, закрыты для модификации. Новое поведение добавляется новым кодом, не правкой существующего. Strategy / plugin / dispatch over switch. Нарушение → каждый new feature требует касания работающих стабильных модулей.

L — Liskov Substitution Principle. Подтипы должны быть drop-in заменой базового типа без сюрпризов. Если Square extends Rectangle и setWidth ломает invariant rectangle — это нарушение LSP. Нарушение → defensive проверки `instanceof` расползаются по коду.

I — Interface Segregation Principle. Клиенты не должны зависеть от методов, которые они не используют. Лучше много маленьких интерфейсов, чем один большой. Нарушение → изменение интерфейса каскадирует на клиентов, которым этот метод не нужен.

D — Dependency Inversion Principle. Высокоуровневые модули не должны зависеть от низкоуровневых; оба должны зависеть от абстракций. Бизнес-логика владеет интерфейсами, инфраструктура реализует. Нарушение → бизнес-код привязан к конкретной БД / framework / SDK.

Граничные случаи и критика:

В функциональных языках без классических иерархий некоторые принципы трансформируются: LSP теряет прямой смысл без наследования (но превращается в parametric polymorphism + property-based testing); ISP размывается с traits / typeclasses (но становится «не требуй больше, чем используешь»). SOLID — это OOP-формулировка более общих принципов.

Связки с другими законами:

— Conway (sect.3): SOLID определяет class-level structure; Conway определяет, какая team-структура её произведёт.
— Conceptual Integrity (sect.30): SOLID — конкретный механизм поддержания integrity на классовом уровне.
— Lehman (sect.23): нарушения SOLID — главный двигатель роста accidental complexity.
— Dependency Rule (sect.35): макро-аналог DIP; то же правило на уровне слоёв архитектуры.

Formulated by Robert C. Martin in the 2000s; acronym by Michael Feathers. Each principle has predictive power: violating it generates a specific class of problems when the code needs to change.

S — Single Responsibility Principle. A class should have one reason to change. Canonically: «a class should be responsible to a single actor». If you need the word «and» to describe it, that's two classes glued together. Violation → unrelated areas break together.

O — Open/Closed Principle. Entities open to extension, closed to modification. New behavior comes from new code, not edits to existing. Strategy / plugin / dispatch over switch. Violation → every new feature requires touching stable working modules.

L — Liskov Substitution Principle. Subtypes must be drop-in replacements for the base type without surprises. If Square extends Rectangle and setWidth breaks the rectangle invariant — that's an LSP violation. Violation → defensive `instanceof` checks spread through the code.

I — Interface Segregation Principle. Clients shouldn't depend on methods they don't use. Many small interfaces beat one large one. Violation → an interface change cascades to clients that don't need that method.

D — Dependency Inversion Principle. High-level modules shouldn't depend on low-level modules; both should depend on abstractions. Business logic owns the interfaces; infrastructure implements them. Violation → business code tied to a specific DB / framework / SDK.

Edge cases and critique:

In functional languages without classical hierarchies some principles transform: LSP loses its literal sense without inheritance (but becomes parametric polymorphism + property-based testing); ISP blurs with traits / typeclasses (but becomes «don't require more than you use»). SOLID is the OOP formulation of more general principles.

Ties to other laws:

— Conway (sect.3): SOLID defines class-level structure; Conway defines which team structure produces it.
— Conceptual Integrity (sect.30): SOLID is the specific mechanism of integrity at class level.
— Lehman (sect.23): SOLID violations are the main driver of accidental complexity growth.
— Dependency Rule (sect.35): the macro counterpart of DIP; the same principle at the layer level.

Роберт Мартин, Clean Architecture, 2017. Центральный тезис: код устроен концентрическими слоями, и зависимости в исходниках разрешены только в одном направлении — внутрь.

Четыре канонических слоя (от центра наружу):

1. Entities — самые стабильные бизнес-правила. То, что верно для домена независимо от приложения. Изменяются реже всего.
2. Use Cases — application-specific бизнес-правила. Сценарии работы конкретного приложения. Знают про Entities, не знают про UI / БД / framework.
3. Interface Adapters — преобразователи форматов. Controllers, presenters, gateways. Конвертируют данные между Use Cases и внешним миром.
4. Frameworks & Drivers — самое нестабильное: web framework, БД, UI, внешние API. Меняется чаще всего.

Главное правило: исходный код во внутреннем слое не должен содержать имени ни одного класса / функции из внешнего слоя. Use Case не импортирует Postgres-driver. Entity не импортирует HTTP-framework. Это макро-аналог DIP из SOLID (sect.34): то же правило, но на уровне слоёв, а не классов.

Как нарушается на практике:

— Active Record паттерн (Entity знает про БД) — нарушение.
— Use Case возвращает HTTP-response объект — нарушение.
— Domain model с annotations Spring/JPA — нарушение в чистом виде, но прагматический компромисс.

Зачем это нужно:

1. Замена framework без переписывания логики. Сменить Spring на что-то другое — изменения только во внешнем слое.
2. Тестируемость бизнес-логики без БД и сети. Use Case тестируется как чистая функция с моками портов.
3. Замедление каскада изменений. Изменение в БД-схеме не должно касаться Entities.

Связки:

— SOLID (sect.34): Dependency Rule = DIP на макро-уровне.
— Hyrum (sect.6): чем глубже слой, тем строже фактический контракт; внутренние слои не могут позволить себе наблюдаемое поведение, не описанное в спеке.
— Lehman (sect.23): Dependency Rule прямо тормозит рост accidental complexity, потому что не даёт связям расти во все стороны.
— Conway (sect.3): чтобы Dependency Rule работал, нужна команда, в которой бизнес-логика и infrastructure имеют разные владельцев — иначе границы размоются.

Критика и граничные случаи: в небольших CRUD-приложениях полная Clean Architecture — over-engineering. Целостный whole product (sect.32) для MVP в Explore-фазе (sect.16) не нужен. Dependency Rule окупается, когда система живёт долго, framework предполагается заменять, бизнес-логика сложна.

Robert C. Martin, Clean Architecture, 2017. The central thesis: code is organized in concentric layers, and source-code dependencies are allowed in one direction only — inward.

Four canonical layers (center outward):

1. Entities — the most stable business rules. What's true about the domain regardless of the application. Changes least often.
2. Use Cases — application-specific business rules. Workflows of this particular app. Know Entities; don't know UI / DB / framework.
3. Interface Adapters — format converters. Controllers, presenters, gateways. Convert data between Use Cases and the outside world.
4. Frameworks & Drivers — the most volatile: web framework, DB, UI, external APIs. Changes most often.

The core rule: code in an inner layer must contain no name of any class / function from an outer layer. A Use Case doesn't import a Postgres driver. An Entity doesn't import an HTTP framework. This is the macro counterpart of DIP from SOLID (sect.34): the same principle, at the layer level instead of the class level.

How it's violated in practice:

— Active Record pattern (Entity knows about DB) — violation.
— A Use Case returns an HTTP-response object — violation.
— Domain model with Spring/JPA annotations — strict violation, common pragmatic compromise.

Why it matters:

1. Replace the framework without rewriting business logic. Swap Spring for something else — changes only in the outer layer.
2. Test business logic without DB or network. A Use Case tests as a pure function with mocked ports.
3. Slow the cascade of changes. A DB schema change should not touch Entities.

Ties:

— SOLID (sect.34): Dependency Rule = DIP at macro scale.
— Hyrum (sect.6): the deeper the layer, the stricter its actual contract; inner layers cannot afford observable behavior not in the spec.
— Lehman (sect.23): Dependency Rule directly retards accidental complexity growth by forbidding links from spreading in all directions.
— Conway (sect.3): for Dependency Rule to actually hold, the team must separate business-logic and infrastructure ownership — otherwise boundaries blur.

Critique and edge cases: for small CRUD apps full Clean Architecture is over-engineering. A whole product (sect.32) for an MVP in the Explore phase (sect.16) doesn't need it. The Dependency Rule pays off when the system lives long, the framework is expected to change, and the business logic is complex.

Роберт Мартин адаптировал из Boy Scout Rule (Lord Baden-Powell): «оставь лагерь чище, чем нашёл». В коде это значит: каждый раз, когда касаешься файла — переименуй непонятную переменную, разнеси длинную функцию, удали закомментированный код, упрости условие.

Tactical, не strategic. Boy Scout — это не sprint на рефакторинг и не «техдолг квартал». Это микро-движение в каждом commit. Размер изменения должен быть таким, чтобы PR ревьюер не заметил его как отдельную работу — это улучшения «на пути» к основной задаче.

Прямой operational ответ Леману (sect.23): Lehman утверждает, что complexity растёт монотонно без активного снижения. Boy Scout — это тактика такого активного снижения, дешёвая в применении и встроенная в обычный workflow. Альтернатива (выделенные «refactoring sprints») — дороже, реже происходит, проваливается под политическим давлением приоритетов.

Что считается «чище»:

— Имена точнее (`d` → `daysElapsed`);
— Функция короче (длинная разбита на меньшие);
— Меньше уровней вложенности (early return вместо if-else-pyramid);
— Test coverage чуть выше (один тест на трогаемое поведение);
— Меньше магических чисел и строк (вынесено в константу);
— Меньше комментариев «что» (заменены на самоописательный код).

Что НЕ считается:

— Большой рефакторинг не относящийся к текущей задаче — это создаёт нечитаемые PR.
— «Улучшение» из субъективных предпочтений (мой стиль скобок vs твой).
— Смена архитектурного подхода — это требует обсуждения, не контрабандой в PR.

Граничный случай и критика: в командной работе over-применение Boy Scout создаёт PR-шум — ревьюер не может разделить функциональные изменения и cleanup. Защита: cleanup-коммиты отдельно от feature-коммитов в одном PR (или отдельный PR), всегда с явным сообщением «cleanup: ...».

Связки:

— Lehman (sect.23): Boy Scout — тактическое противодействие закону роста сложности.
— Conceptual Integrity (sect.30): Boy Scout помогает поддерживать целостность инкрементально, без больших ревизий.
— SOLID (sect.34): большинство Boy Scout-улучшений в реальности — это маленькие шаги в сторону соблюдения SOLID.
— HOP (sect.21): Boy Scout — операционализация принципа «learning is vital» на уровне кода: каждое касание = микро-урок, оставленный в виде улучшения.

Robert C. Martin adapted from Lord Baden-Powell's Boy Scout Rule: «leave the camp cleaner than you found it». In code: every time you touch a file — rename an unclear variable, split a long function, delete commented-out code, simplify a condition.

Tactical, not strategic. Boy Scout isn't a refactor sprint or a «tech-debt quarter». It's micro-movement in every commit. The change size should be small enough that a PR reviewer wouldn't flag it as separate work — these are improvements «on the way» to the main task.

A direct operational answer to Lehman (sect.23): Lehman states complexity grows monotonically without active reduction. Boy Scout is the tactic for that active reduction, cheap to apply and embedded in normal workflow. The alternative (dedicated «refactoring sprints») is more expensive, happens rarely, and dies under priority pressure.

What counts as «cleaner»:

— A more precise name (`d` → `daysElapsed`);
— A shorter function (a long one split into smaller);
— Less nesting (early return instead of if-else pyramid);
— Slightly better test coverage (one test on the behavior you touched);
— Fewer magic numbers and strings (extracted to constants);
— Fewer «what» comments (replaced by self-describing code).

What does NOT count:

— A large refactor unrelated to the current task — it makes PRs unreadable.
— «Improvement» from subjective preference (my brace style vs yours).
— Changing the architectural approach — that needs discussion, not contraband in a PR.

Edge case and critique: in team work, over-applying Boy Scout creates PR noise — the reviewer can't separate functional changes from cleanup. Defense: cleanup commits separately from feature commits in one PR (or a separate PR), always with an explicit message «cleanup: ...».

Ties:

— Lehman (sect.23): Boy Scout is the tactical counter to the complexity-growth law.
— Conceptual Integrity (sect.30): Boy Scout helps maintain integrity incrementally, without large overhauls.
— SOLID (sect.34): most Boy Scout improvements are, in fact, small steps toward SOLID compliance.
— HOP (sect.21): Boy Scout operationalizes «learning is vital» at the code level: every touch = a micro-lesson left as an improvement.

Алан Купер, The Inmates Are Running the Asylum, 1999. Метафора: на ярмарке люди платят, чтобы посмотреть на медведя, который умеет танцевать — не потому, что он танцует хорошо, а потому что обычно медведи вообще не танцуют. Так же с большинством enterprise- и dev-tools: пользователи терпят чудовищный UX, потому что альтернатив нет.

Признаки того, что ты dancing bear:

1. Пользователи говорят «спасибо, что вообще работает» вместо «удобно».
2. Документация толще, чем продукт.
3. Обучение требует курса, не tooltip'а.
4. Существует Slack-канал или Discord, где пользователи помогают друг другу — потому что официальная поддержка не справляется с базовыми вопросами.
5. У пользователей есть устные обходные пути («сначала нажми X, потом подожди, потом Y, иначе сломается»).

Почему dancing bears выживают:

— Сетевой эффект (миграция дорогая);
— Сильная функциональная уникальность (никто больше этого не делает);
— Switching cost выше boli от плохого UX;
— Pragmatist в той же индустрии уже использует — social proof перевешивает UX-discomfort.

Почему dancing bears уязвимы:

Как только появляется конкурент с такой же функциональностью и приличным UX — миграция начинается мгновенно. Канонические примеры: Slack убил IRC/Skype в enterprise чате; Linear убил JIRA в startup-сегменте; Cursor выгрызает долю у VS Code среди AI-инженеров. Во всех случаях функциональность была уже доступна; новизной был именно UX.

Связки с другими законами:

— Chasm (sect.31): dancing bears пересекают chasm только для визионеров (терпят что угодно ради преимущества); для прагматиков — спотыкаются. Большинство «не пересёкших пропасть» продуктов — dancing bears.
— Whole Product (sect.32): UX — часть expected product, без которой pragmatist не покупает. Dancing bear имеет generic + augmented, но проваливается на expected.
— Старджон (sect.13): 90% всего — мусор, в основном по UX. Хорошая функциональность встречается чаще, чем хороший UX.
— Линди (sect.14): старые dancing bears, выжившие десятилетиями (SAP, Bloomberg Terminal, AutoCAD) — это product moat через switching cost, а не через качество.

Engineering-следствия:

1. Dancing bear — структурное состояние, не баг. Не чинится одним sprint'ом «давайте сделаем интерфейс лучше». Требует переосмысления того, кто пользователь и какие у него цели (см. sect.38).
2. Диагностический тест: если новый пользователь не может выполнить базовую задачу за 10 минут без помощи — ты dancing bear, даже если опытные пользователи довольны.
3. В AI-эре риск выше: AI-tools часто dancing bears — функциональность поразительная («модель пишет код!»), UX часто примитивный (промпт-инжиниринг, копипаст, hidden state). Это окно возможностей для UX-led конкурентов.

Alan Cooper, The Inmates Are Running the Asylum, 1999. The metaphor: at the fair people pay to watch a bear dance — not because it dances well, but because bears normally don't dance at all. Same with most enterprise and dev tools: users tolerate awful UX because there's no alternative.

Signs you're a dancing bear:

1. Users say «thank you that it works at all» instead of «this is comfortable».
2. Documentation is thicker than the product.
3. Onboarding requires a course, not a tooltip.
4. A Slack channel or Discord exists where users help each other — because official support can't handle basics.
5. Users pass around oral workarounds («first click X, wait, then Y, or it breaks»).

Why dancing bears survive:

— Network effects (migration is expensive);
— Strong functional uniqueness (no one else does this);
— Switching cost exceeds bad-UX pain;
— A pragmatist in the same industry already uses it — social proof outweighs UX discomfort.

Why dancing bears are vulnerable:

As soon as a competitor with the same functionality and decent UX appears — migration starts instantly. Canonical examples: Slack killed IRC/Skype in enterprise chat; Linear killed JIRA in the startup segment; Cursor is eating VS Code's share among AI engineers. In every case the functionality was already available; what was new was the UX.

Ties to other laws:

— Chasm (sect.31): dancing bears cross the chasm only for visionaries (who tolerate anything for the advantage); for pragmatists they stall. Most «didn't-cross-the-chasm» products are dancing bears.
— Whole Product (sect.32): UX is part of the expected product, without which a pragmatist doesn't buy. A dancing bear has generic + augmented but fails at expected.
— Sturgeon (sect.13): 90% is crap, mostly via UX. Good functionality is more common than good UX.
— Lindy (sect.14): old dancing bears that survived decades (SAP, Bloomberg Terminal, AutoCAD) — that's a product moat via switching cost, not via quality.

Engineering implications:

1. Dancing bear is a structural state, not a bug. Not fixable by a sprint of «let's make the UI nicer». Requires rethinking who the user is and what their goals are (see sect.38).
2. Diagnostic test: if a new user can't complete a basic task in 10 minutes without help — you're a dancing bear, even if experienced users are happy.
3. Higher risk in the AI era: AI tools are often dancing bears — astonishing functionality («the model writes code!»), often primitive UX (prompt engineering, copy-paste, hidden state). This is an opening for UX-led competitors.

Алан Купер, The Inmates Are Running the Asylum, 1999. Главный тезис книги, давший название: «заключённые управляют психбольницей» — то есть инженеры проектируют интерфейсы, которые используют не-инженеры. И делают это в инженерной логике, которая ортогональна логике пользователя.

Как мыслит программист (это удобно для кода):

— Состояние эксплицитно: всё видимое — флаги, режимы, modal dialogs;
— Опции конфигурируемы: «дадим пользователю выбор» (= ему придётся выбирать);
— Ошибки информативны: «error code 0x80004005» — для отладки идеально;
— Действия атомарны: «нажал кнопку → произошло событие → новое состояние»;
— System-truth важнее пользовательской интенции: «вы пытаетесь сохранить, но файл изменился внешне».

Как мыслит пользователь (это удобно для жизни):

— Состояние имплицитно: «оно само должно знать, чего я хочу»;
— Опции — это бремя: каждый выбор — когнитивный налог;
— Ошибки — это испуг: важно «что мне делать», а не «что случилось»;
— Действия — это намерения: «я хочу X», конкретные кнопки вторичны;
— Своя интенция важнее «истины системы»: «не интересует, что файл изменился — мои изменения главные».

Прямое следствие: когда инженер проектирует UX, он по умолчанию делает интерфейс, в котором ему самому работать удобно. Этого недостаточно. Купер предлагал radical solution — выделить interaction designer как отдельную профессию. Прагматически: senior engineers нуждаются в явной discipline UX-мышления, как они нуждаются в discipline тестирования или security.

Канонические артефакты инженерного UX:

1. Modal dialogs «Are you sure?» на каждое действие — потому что инженер думает в terms «опасных операций» с подтверждением.
2. Бесконечные опции в settings — потому что инженер не хочет принимать решения за пользователя, и каждый case ставит флаг.
3. Error codes — потому что для debugging нужны exact identifiers, не human messages.
4. Plumbing leaks — детали реализации просачиваются в UI: «database connection lost», «cache invalidated», «pod restarted».
5. CLI flags везде — потому что для инженера флаг — это нативная форма опции.

Критика книги Купера: Cooper писал в эру до UX-as-discipline, поэтому его «выделите interaction designer как профессию» сейчас часть нормы. Однако сам bias никуда не делся: senior engineers всё равно проектируют API, error messages, default values, configuration — и всё это часть UX. Главная корректива: UX — это не только UI. API tooling — это UX для других инженеров. Error messages — это UX для on-call инженера. Defaults — это UX для всех. От bias не уйти, делегировав «UX в отдельный департамент».

Связки с другими законами:

— Conway (sect.3): топологический родственник. Conway: «организация производит свою архитектуру». Cooper: «инженер производит свой UX». Оба — о проекции внутренней структуры производителя на продукт.
— Hollnagel (sect.18): "substitution myth" — автоматизация трансформирует систему. Аналогично: программирование интерфейса трансформирует ментальную модель пользователя в инженерную.
— Dancing Bearware (sect.37): механизм возникновения dancing bears. Инженер строит для себя → продукт мучителен для всех остальных → выживает только на функциональной уникальности.
— Старджон (sect.13): 90% UX мусор не случайно. Большинство UX делается инженерами без UX-discipline.
— SOLID (sect.34): симметричное место — те же принципы (Interface Segregation, Dependency Inversion) применимы к UX: пользователь не должен видеть методы, которые ему не нужны; интерфейс не должен зависеть от деталей реализации.

Operational контрмеры: dogfooding с НЕ-инженерами; формальный UX-review; user-testing на 5 случайных людях из target-сегмента; правило «нет error codes без human-readable объяснения»; правило «нет настройки в UI, если default подходит 80% случаев».

Alan Cooper, The Inmates Are Running the Asylum, 1999. The central thesis that gave the book its title: «the inmates run the asylum» — that is, engineers design interfaces used by non-engineers, in engineering logic that's orthogonal to user logic.

How a programmer thinks (good for code):

— State is explicit: everything visible — flags, modes, modal dialogs;
— Options are configurable: «let the user choose» (= they have to choose);
— Errors are informative: «error code 0x80004005» — perfect for debugging;
— Actions are atomic: «pressed button → event fired → new state»;
— System truth beats user intent: «you tried to save but the file changed externally».

How a user thinks (good for life):

— State is implicit: «it should just know what I want»;
— Options are burden: every choice is a cognitive tax;
— Errors are panic: what matters is «what should I do», not «what happened»;
— Actions are intents: «I want X», specific buttons are secondary;
— Their intent beats «system truth»: «I don't care that the file changed — my changes win».

Direct consequence: when an engineer designs UX, they default to building an interface that they themselves are comfortable working in. That's not enough. Cooper proposed a radical solution — make interaction designer a separate profession. Pragmatically: senior engineers need explicit UX-thinking discipline the same way they need testing or security discipline.

Canonical artifacts of engineer-designed UX:

1. Modal dialogs «Are you sure?» on every action — because engineers think in terms of «dangerous operations with confirmation».
2. Infinite options in settings — because engineers don't want to decide for the user, and every case becomes a flag.
3. Error codes — because debugging needs exact identifiers, not human messages.
4. Plumbing leaks — implementation details leak into UI: «database connection lost», «cache invalidated», «pod restarted».
5. CLI flags everywhere — because for an engineer, a flag is the native form of an option.

Critique of Cooper: Cooper wrote pre-UX-as-discipline, so his «make interaction designer a separate profession» is now normal. But the bias itself didn't go away: senior engineers still design APIs, error messages, default values, configuration — and all of those are UX. Key correction: UX isn't just UI. API tooling is UX for other engineers. Error messages are UX for on-call engineers. Defaults are UX for everyone. You can't delegate the bias away by «sending UX to a separate department».

Ties to other laws:

— Conway (sect.3): topological cousin. Conway: «the organization produces its architecture». Cooper: «the engineer produces their UX». Both about projecting the producer's internal structure onto the product.
— Hollnagel (sect.18): «substitution myth» — automation transforms the system. Same here: programming an interface transforms the user's mental model into the engineer's.
— Dancing Bearware (sect.37): the mechanism behind dancing bears. Engineer builds for themselves → product is painful for everyone else → survives only on functional uniqueness.
— Sturgeon (sect.13): 90% of UX being crap isn't random. Most UX is designed by engineers without UX discipline.
— SOLID (sect.34): symmetric application — the same principles (Interface Segregation, Dependency Inversion) apply to UX: the user shouldn't see methods they don't need; the interface shouldn't depend on implementation details.

Operational countermeasures: dogfooding with NON-engineers; formal UX review; user testing with 5 random people from the target segment; rule «no error codes without a human-readable explanation»; rule «no setting in the UI if a default works for 80% of cases».

Термин «code smell» предложил Кент Бек, систематический каталог собрал Мартин Фаулер в Refactoring (1999, 2018). Главная философия: рефакторинг — это не «переписать», а серия мелких безопасных трансформаций, у каждой из которых есть имя и рецепт.

Каталог канонических запахов (часть):

1. Long Method — функция длиннее одного экрана. Рефакторинг: Extract Method.
2. Large Class — класс с большим количеством полей/методов. Рефакторинг: Extract Class / Extract Subclass.
3. Long Parameter List — больше 3-4 параметров. Рефакторинг: Introduce Parameter Object, или передать сам объект-носитель.
4. Duplicate Code — то же самое в разных местах. Рефакторинг: Extract Method / Pull Up Method.
5. Feature Envy — метод одного класса больше использует поля другого. Рефакторинг: Move Method.
6. Data Clumps — одни и те же 3-4 поля кочуют группой везде. Рефакторинг: Extract Class на эту группу.
7. Primitive Obsession — string/int вместо собственного типа (email как string, money как int). Рефакторинг: Replace Primitive with Object.
8. Switch Statements — длинный switch по типу. Рефакторинг: Replace Conditional with Polymorphism.
9. Shotgun Surgery — одно изменение требует правок в 10 местах. Рефакторинг: Move Method/Field для собирания вместе.
10. Divergent Change — один класс меняется по 5 разным причинам. Рефакторинг: Extract Class (нарушение SRP из SOLID, sect.34).
11. Speculative Generality — абстракция «на будущее», не использующаяся сейчас. Рефакторинг: Inline / Remove. YAGNI.
12. Comments — комментарии «что» вместо самоописательного кода. Часто маркер запаха.

Главная сила каталога — общий словарь. Без него code review превращается в спор о вкусах. С ним фраза «это Feature Envy, давай сделаем Move Method» закрывает дискуссию: разговор перешёл с предпочтений на конкретный паттерн с конкретным решением.

Граничные случаи и критика:

Фаулер писал в эру OOP-Java (1999), и часть запахов — это специфически ООП-проблемы. Switch Statements в FP — это нормальный pattern matching, не запах. Primitive Obsession в Rust решается через newtype-pattern, не через class. Каталог — это не догма, а лексикон. Контекст языка диктует, какие запахи применимы.

Связки с другими законами:

— Boy Scout (sect.36): Boy Scout — это когда рефакторить (постоянно, понемногу). Code Smells — что рефакторить (диагностика). Без smells Boy Scout превращается в случайные мелкие изменения; вместе они дают системный поток улучшений.
— SOLID (sect.34): большинство smells — это симптомы нарушений SOLID. Divergent Change = SRP нарушен. Switch Statements = OCP нарушен. Shotgun Surgery = плохая cohesion. Code Smells — диагностический язык для SOLID-violations.
— Lehman (sect.23): запахи — это маркеры accumulating complexity. Без активной диагностики они накапливаются, пока не превратятся в structural debt.
— HOP (sect.21): code review с общим словарём smells = blameless review. Обсуждается паттерн, не личность инженера.

В контексте AI-augmented coding: AI-generated код особенно склонен к Speculative Generality, Long Method, Primitive Obsession и Duplicate Code — модель оптимизирует под «работающее решение», не под «минимальное и чистое». Каталог запахов даёт инженеру checklist для review AI-кода: «что из 22 канонических симптомов проявилось?»

Kent Beck coined the term «code smell»; Martin Fowler built the systematic catalog in Refactoring (1999, 2018). Core philosophy: refactoring isn't «rewrite», it's a sequence of small safe transformations, each with a name and a recipe.

Canonical smells catalog (partial):

1. Long Method — function longer than one screen. Refactor: Extract Method.
2. Large Class — class with many fields/methods. Refactor: Extract Class / Extract Subclass.
3. Long Parameter List — more than 3-4 parameters. Refactor: Introduce Parameter Object, or pass the carrying object itself.
4. Duplicate Code — same thing in different places. Refactor: Extract Method / Pull Up Method.
5. Feature Envy — a method of one class uses another's fields more than its own. Refactor: Move Method.
6. Data Clumps — the same 3-4 fields travel as a group everywhere. Refactor: Extract Class on that group.
7. Primitive Obsession — string/int instead of a proper type (email as string, money as int). Refactor: Replace Primitive with Object.
8. Switch Statements — long switch on type. Refactor: Replace Conditional with Polymorphism.
9. Shotgun Surgery — one change requires edits in 10 places. Refactor: Move Method/Field to bring related parts together.
10. Divergent Change — one class changes for 5 different reasons. Refactor: Extract Class (SRP violation from SOLID, sect.34).
11. Speculative Generality — abstraction «for the future», not used now. Refactor: Inline / Remove. YAGNI.
12. Comments — «what» comments instead of self-describing code. Often a smell marker.

The catalog's main power is shared vocabulary. Without it, code review turns into taste arguments. With it, «that's Feature Envy, let's do Move Method» closes the discussion: the conversation moved from preferences to a specific pattern with a specific solution.

Edge cases and critique:

Fowler wrote in the OOP-Java era (1999), and some smells are specifically OOP problems. Switch Statements in FP are normal pattern matching, not a smell. Primitive Obsession in Rust is solved via newtype pattern, not via a class. The catalog isn't dogma, it's a lexicon. Language context dictates which smells apply.

Ties to other laws:

— Boy Scout (sect.36): Boy Scout is when to refactor (always, in small steps). Code Smells are what to refactor (diagnostics). Without smells, Boy Scout becomes random small changes; together they produce a systematic flow of improvement.
— SOLID (sect.34): most smells are symptoms of SOLID violations. Divergent Change = SRP broken. Switch Statements = OCP broken. Shotgun Surgery = bad cohesion. Code Smells are the diagnostic language for SOLID violations.
— Lehman (sect.23): smells are markers of accumulating complexity. Without active diagnosis they pile up until they become structural debt.
— HOP (sect.21): code review with shared smell vocabulary = blameless review. The pattern is discussed, not the engineer's identity.

In the context of AI-augmented coding: AI-generated code is especially prone to Speculative Generality, Long Method, Primitive Obsession, and Duplicate Code — the model optimizes for «working solution», not «minimal and clean». The smells catalog gives the engineer a checklist for reviewing AI code: «which of the 22 canonical symptoms showed up?»

Мартин Фаулер, эссе 2004 года. Название из ботаники: strangler fig (фикус-душитель) растёт обвиваясь вокруг дерева-хозяина, постепенно перехватывая его доступ к свету и влаге; в итоге дерево умирает, а фикус остаётся стоять на его месте как полая структура.

Применительно к legacy: вместо big-bang переписывания (которое почти всегда проваливается) — строится новая система рядом со старой. Постепенно функция за функцией мигрируют: новые запросы идут в новую систему, старые — пока в старую. Через год-два старая система остаётся без живых обращений и удаляется.

Канонический механизм:

1. Façade (interception layer) — прокси перед старой системой, через который проходит весь трафик. Изначально просто пропускает запросы.
2. Migrate one slice at a time. Берётся одна функция (один endpoint, один Use Case). Реализуется в новой системе. Façade перенаправляет именно этот срез в новую систему.
3. Two writes / single read при переходных состояниях: данные пишутся в обе системы, читаются из одной. Это даёт возможность параллельной верификации.
4. Old system shrinks. Каждая мигрированная функция — это «удушение» куска старой системы. Через N итераций старая система — пустая оболочка.
5. Decommission. Когда живых вызовов не осталось — удаление.

Почему big-bang проваливается:

— Старая система — это не код, это интегрированный whole product (sect.32) с обходными путями, hack'ами, скрытыми зависимостями (закон Хайрама, sect.6).
— Воссоздать всю функциональность с нуля — это всегда ×9 от оценки (Брукс, sect.27).
— Бизнес не может на год остановиться для замены инструмента.
— Это всегда second-system effect (sect.29) — команда хочет «сделать правильно», и продукт превращается в over-engineered платформу.

Почему StranglerFig работает:

— Risk amortization: каждая итерация — маленькое изменение с быстрой обратной связью; рискуется только один срез, не вся миграция.
— Continuous value: бизнес получает улучшения по мере того, как каждый кусок мигрирует, а не через 2 года.
— Reversibility: если итерация провалилась — Façade переключает обратно. Big-bang не имеет undo.
— Learning loop: первые срезы учат команду реальной structure старой системы. Big-bang предполагает, что вы знаете её заранее (обычно — иллюзия).

Когда НЕ применять StranglerFig:

1. Старая система — это true legacy (нельзя добавить façade, нельзя писать в обе).
2. Параллельная работа двух систем нарушает регуляторные требования.
3. Объём миграции маленький (две недели) — overhead на façade не оправдан.
4. Команда не имеет дисциплины поддерживать две системы одновременно.

Связки с другими законами:

— Брукс ×9 (sect.27): StranglerFig — это стратегия выживания против ×9 множителя при замене systems product. Big-bang платит ×9 сразу; StranglerFig платит по частям, с возможностью остановиться.
— Second-System (sect.29): прямой контрапункт. Big-bang переписывание — это second-system effect на максимуме. StranglerFig структурно не даёт ему развернуться: каждая итерация ограничена одним срезом, нет места для «давайте перепроектируем всё».
— Lehman (sect.23): StranglerFig — стратегия применения continuing change в условиях, когда система слишком велика для in-place эволюции.
— Boy Scout (sect.36): StranglerFig — это Boy Scout на макро-уровне. Те же принципы (маленькие шаги, постоянное движение), но не на файлах, а на целых модулях.
— Chasm (sect.31): StranglerFig — техника безопасной миграции архитектуры, когда продукт уже пересёк chasm и нельзя себе позволить downtime.

В контексте AI-augmented coding: AI делает StranglerFig дешевле, чем когда-либо. Раньше barrier был в стоимости параллельной реализации функций; AI снижает её. Это структурно сдвигает порог принятия решения «переписать или развивать» в сторону переписывания через strangler, потому что cost этой стратегии падает.

Martin Fowler, 2004 essay. Name from botany: the strangler fig grows wrapping around a host tree, gradually intercepting its access to light and moisture; eventually the tree dies and the fig stands in its place as a hollow structure.

Applied to legacy: instead of a big-bang rewrite (which almost always fails) — a new system is built alongside the old one. Function by function, it migrates: new requests go to the new system, old ones stay in the old. Over a year or two the old system has no live callers and gets removed.

The canonical mechanism:

1. Façade (interception layer) — proxy in front of the old system through which all traffic flows. Initially just passes requests through.
2. Migrate one slice at a time. Take one function (one endpoint, one Use Case). Implement it in the new system. The façade routes that specific slice to the new system.
3. Two writes / single read during transitional states: data is written to both systems, read from one. This enables parallel verification.
4. Old system shrinks. Each migrated function is a piece of the old system «strangled». After N iterations the old system is an empty shell.
5. Decommission. When no live calls remain — removal.

Why big-bang fails:

— The old system isn't code, it's an integrated whole product (sect.32) with workarounds, hacks, hidden dependencies (Hyrum's Law, sect.6).
— Recreating all functionality from scratch always costs ×9 of the estimate (Brooks, sect.27).
— The business can't stop for a year to swap tools.
— It's always a second-system effect (sect.29) — the team wants to «do it right», and the product becomes an over-engineered platform.

Why StranglerFig works:

— Risk amortization: each iteration is a small change with fast feedback; only one slice is at risk, not the whole migration.
— Continuous value: the business gets improvements as each slice migrates, not after 2 years.
— Reversibility: if an iteration fails — the façade switches back. Big-bang has no undo.
— Learning loop: the first slices teach the team the real structure of the old system. Big-bang assumes you already know it (usually an illusion).

When NOT to use StranglerFig:

1. The old system is true legacy (can't add a façade, can't dual-write).
2. Parallel operation of two systems violates regulatory requirements.
3. The migration is small (two weeks) — façade overhead isn't worth it.
4. The team lacks the discipline to operate two systems concurrently.

Ties to other laws:

— Brooks ×9 (sect.27): StranglerFig is the survival strategy against the ×9 multiplier when replacing a systems product. Big-bang pays ×9 up front; StranglerFig pays piecewise, with an option to stop.
— Second-System (sect.29): a direct counter. Big-bang rewriting is second-system at its peak. StranglerFig structurally prevents it from unfolding: each iteration is bounded to a single slice, no room for «let's redesign everything».
— Lehman (sect.23): StranglerFig is the strategy for applying continuing change when the system is too large for in-place evolution.
— Boy Scout (sect.36): StranglerFig is Boy Scout at macro scale. Same principles (small steps, continuous motion), but on whole modules, not on files.
— Chasm (sect.31): StranglerFig is the safe-migration technique when the product has already crossed the chasm and downtime isn't an option.

In the context of AI-augmented coding: AI makes StranglerFig cheaper than ever. The historic barrier was the cost of building parallel implementations; AI lowers it. This structurally shifts the «rewrite vs evolve» decision threshold toward the strangler approach, because that strategy's cost drops.

Алистер Кокберн, статья «Hexagonal Architecture», 2005. Позже популяризировано Робертом Мартином как часть Clean Architecture (2012, 2017) и отчасти повторено в Onion Architecture Палермо (2008). Все три — варианты одной идеи.

Механизм:

1. Port — это интерфейс (в смысле абстракции / контракта), принадлежащий внутреннему слою. Он формулируется на языке домена: «нужен способ сохранить заказ», «нужен способ отправить уведомление».
2. Adapter — реализация порта во внешнем слое. Postgres-adapter реализует «нужен способ сохранить заказ» через SQL. SMTP-adapter реализует «нужен способ отправить уведомление» через email. AWS-SNS-adapter — тот же интерфейс, но через push.
3. Inversion: в наивной архитектуре business-код импортирует БД-драйвер. В Ports & Adapters business-код определяет интерфейс, а БД-драйвер обёрнут в adapter, который его реализует. Импорт идёт изнутри-наружу в обратном направлении относительно потока вызовов.

Два разных направления — главный insight паттерна:

— Direction of dependencies (источники импортируют): только внутрь. Outer → Inner.
— Direction of flow of control (вызовы во время работы): через границы в обе стороны, но «логически» наружу. Controller вызывает Use Case Input Port → Use Case Interactor вызывает Use Case Output Port → Presenter / Database Adapter.

Это разные оси. Можно зависеть от чего-то и вызывать его — это знакомо. Можно вызывать что-то не зависеть от него — это и есть Inversion. Реализуется тем, что вызываемое определяется интерфейсом, который принадлежит вызывающему слою.

Канонический поток Use Case:

Controller (outer) → Use Case Input Port (inner interface) → Use Case Interactor (inner impl) → Use Case Output Port (inner interface) → Presenter (outer impl)

В этой цепочке Controller и Presenter — это adapters. Input Port и Output Port — это ports, определённые внутри. Interactor — это бизнес-логика, которая знает только про свои собственные ports, не про конкретные Controller / Presenter.

Что это даёт на практике:

1. Замена адаптеров без касания core. Postgres → MongoDB: меняется один adapter, бизнес-логика не знает, что произошло.
2. Тестирование core как чистой функции. Подставляем in-memory mock-adapter для всех ports. Use Case тестируется без БД, сети, framework.
3. Multiple adapters одного порта. «Сохранить заказ» может реализовываться и в БД, и в файл, и в memory — всё одновременно (например, для shadow-writes при миграции, см. StranglerFig sect.40).
4. Чёткая граница ответственности. Если adapter ломается — проблема в integration. Если бизнес-логика ломается — проблема в core. Границы помогают локализовать debugging.

Канонические ошибки реализации:

— Анемичные ports. Интерфейс называется UserRepository и имеет методы save(), findById(), findByEmail() — это не port в смысле паттерна, это CRUD-абстракция над БД, протекающая через core. Настоящий port: OrderPlacement с методом persistPlacedOrder(order: PlacedOrder) — formulated на языке домена.
— Adapters, утекающие свои детали. Если UserRepository.findById возвращает SqlRow или бросает SQLException — abstraction нарушена. Adapter должен переводить детали в domain-объекты на границе.
— Direction confusion. Adapter импортирует port — правильно. Port импортирует adapter — нарушение Inversion.

Когда НЕ применять:

1. CRUD-приложение с тривиальной бизнес-логикой — ports добавляют overhead без значимой выгоды.
2. MVP в Explore-фазе (sect.16) — преждевременная абстракция.
3. Прототип / one-off скрипт — accidental complexity без essential выгоды (sect.28).

Связки с другими законами:

— Dependency Rule (sect.35): Ports & Adapters — это конкретный механизм реализации Dependency Rule. sect.35 говорит «зависимости внутрь»; sect.41 говорит как именно сделать это технически, когда нужно вызывать что-то снаружи.
— SOLID / DIP (sect.34): Ports & Adapters — это DIP на макро-уровне. Класс-level DIP формулируется как «завись от абстракции, не от реализации»; макро-уровень — «слой определяет интерфейс, другой слой реализует».
— Hyrum's Law (sect.6): чем чище abstraction port'а, тем меньше клиенты зависят от деталей реализации adapter'а. Утекающие детали через слабо спроектированный port → клиенты подсаживаются на специфику конкретного adapter'а.
— Lehman (sect.23): Ports & Adapters замедляют рост accidental complexity, не давая инфраструктурным деталям распространяться в core.
— StranglerFig (sect.40): Ports & Adapters — это инфраструктура для миграции. Façade — это adapter, переключающий между old и new реализациями одного port'а.

Историческая нота: Кокберн придумал Hexagonal Architecture в 2005, заметив, что классическая многослойная архитектура трактует UI и БД асимметрично (UI наверху, БД внизу). Гексагон сделал их симметричными — оба просто адаптеры на границе. Шесть граней изначально не имели специального значения; это была визуализация «много возможных адаптеров». Onion (2008) и Clean Architecture (2012) развили ту же идею с большей детализацией слоёв.

Alistair Cockburn, «Hexagonal Architecture», 2005. Later popularized by Robert C. Martin as part of Clean Architecture (2012, 2017) and partly echoed in Palermo's Onion Architecture (2008). All three are variants of the same idea.

The mechanism:

1. Port — an interface (in the abstraction / contract sense) owned by the inner layer. Formulated in domain language: «need a way to persist an order», «need a way to send a notification».
2. Adapter — implementation of the port in the outer layer. Postgres adapter implements «persist an order» via SQL. SMTP adapter implements «send a notification» via email. An AWS SNS adapter — same interface, but via push.
3. Inversion: in a naive architecture, business code imports the DB driver. In Ports & Adapters, business code defines the interface, and the DB driver is wrapped in an adapter that implements it. Import direction goes from inside outward, reverse to the call direction.

Two different directions — the main insight of the pattern:

— Direction of dependencies (source-code imports): inward only. Outer → Inner.
— Direction of flow of control (runtime calls): crosses boundaries in both ways, but «logically» outward. Controller calls Use Case Input Port → Use Case Interactor calls Use Case Output Port → Presenter / Database Adapter.

These are different axes. You can depend on something and call it — that's familiar. You can call something without depending on it — that's Inversion. It works because the called party is defined by an interface owned by the caller's layer.

The canonical Use Case flow:

Controller (outer) → Use Case Input Port (inner interface) → Use Case Interactor (inner impl) → Use Case Output Port (inner interface) → Presenter (outer impl)

In this chain Controller and Presenter are adapters. Input Port and Output Port are ports defined inside. Interactor is business logic that only knows about its own ports, not about specific Controllers / Presenters.

What this gives you in practice:

1. Swap adapters without touching the core. Postgres → MongoDB: one adapter changes; the business logic never knows.
2. Test the core as a pure function. Substitute an in-memory mock adapter for every port. The Use Case tests without DB, network, framework.
3. Multiple adapters per port. «Persist order» can be implemented to DB, to file, to memory — all at the same time (e.g., shadow writes during migration, see StranglerFig sect.40).
4. Clear ownership boundaries. If an adapter breaks — integration problem. If business logic breaks — core problem. Boundaries help localize debugging.

Canonical implementation errors:

— Anemic ports. An interface called UserRepository with save(), findById(), findByEmail() — that's not a port in the pattern sense, it's a CRUD abstraction over the DB leaking through the core. A real port: OrderPlacement with persistPlacedOrder(order: PlacedOrder) — formulated in domain language.
— Adapters leaking their details. If UserRepository.findById returns SqlRow or throws SQLException — the abstraction is broken. The adapter must translate details into domain objects at the boundary.
— Direction confusion. Adapter imports port — correct. Port imports adapter — Inversion violated.

When NOT to apply:

1. CRUD application with trivial business logic — ports add overhead without meaningful benefit.
2. MVP in the Explore phase (sect.16) — premature abstraction.
3. Prototype / one-off script — accidental complexity without essential gain (sect.28).

Ties to other laws:

— Dependency Rule (sect.35): Ports & Adapters is the specific mechanism realizing the Dependency Rule. sect.35 says «dependencies inward»; sect.41 says how to make it work technically when you need to call something outward.
— SOLID / DIP (sect.34): Ports & Adapters is DIP at macro scale. Class-level DIP says «depend on abstractions, not implementations»; macro-level says «the layer defines the interface, another layer implements it».
— Hyrum's Law (sect.6): the cleaner the port's abstraction, the less clients depend on adapter-implementation details. Leaking details through a poorly designed port → clients become hooked on a specific adapter's quirks.
— Lehman (sect.23): Ports & Adapters slow the growth of accidental complexity by stopping infrastructure details from spreading into the core.
— StranglerFig (sect.40): Ports & Adapters is the infrastructure for migration. The façade is an adapter switching between old and new implementations of the same port.

Historical note: Cockburn invented Hexagonal Architecture in 2005 noticing that classic layered architecture treats UI and DB asymmetrically (UI on top, DB on bottom). The hexagon made them symmetric — both just adapters at the boundary. The six sides originally had no special meaning; it was a visualization of «many possible adapters». Onion (2008) and Clean Architecture (2012) extended the same idea with more layer detail.

Илон Маск, многократно сформулировано в Tesla и SpaceX. Пять шагов engineering process:

1. Question requirements. Подвергни сомнению каждое требование. Самые опасные — от умных людей, их не оспаривают. У каждого требования должен быть конкретный автор — не «департамент». Даже требования самого Маска подлежат сомнению.
2. Delete. Удали всё, что можешь. Если не пришлось вернуть минимум ~10% удалённого — удалял недостаточно. Удалить шаг, компонент, ограничение, документ, тест.
3. Simplify & Optimize. Только после удаления. Самая частая ошибка умного инженера — оптимизировать то, что не должно существовать.
4. Accelerate cycle time. Ускоряй цикл — но только после шагов 1–3. «Если копаешь себе могилу — не копай быстрее».
5. Automate. Автоматизация идёт последней. Главная ошибка инженеров — автоматизировать хаос.

Почему порядок критичен: каждый следующий шаг встроен в предыдущий. Автоматизировать упрощённое — дёшево. Автоматизировать неудалённое — закрепить лишнее в коде на годы. Оптимизировать неоспорённое требование — построить cathedral вокруг illusion.

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

Связки: sect.5 (Завински) — feature creep растёт без шага 2. sect.29 (Second-System) — попытка перейти к шагу 3 без 1-2. sect.18 (Hollnagel) — шаг 5 без 2 как substitution myth. sect.36 (Boy Scout) — операционный режим непрерывного применения 2-3.

Elon Musk, formulated repeatedly at Tesla and SpaceX. Five steps of the engineering process:

1. Question requirements. Challenge every requirement. The most dangerous come from smart people — they don't get challenged. Every requirement must have a specific author, not «a department». Even Musk's own requirements are subject to challenge.
2. Delete. Delete everything you can. If you don't have to add back at least ~10% of what you deleted — you didn't delete enough. Delete a step, component, constraint, document, test.
3. Simplify & Optimize. Only after deletion. The smart engineer's most common mistake is optimizing what shouldn't exist.
4. Accelerate cycle time. Speed up the cycle — but only after steps 1-3. «If you're digging your own grave, don't dig faster».
5. Automate. Automation comes last. Engineers' biggest mistake is automating chaos.

Why order matters: each step builds on the previous. Automating the simplified — cheap. Automating the un-deleted — locking excess into code for years. Optimizing an unchallenged requirement — building a cathedral around an illusion.

Signals the order is broken: «let's automate first, then simplify», «we'll optimize the existing process», «requirements are signed off, too late to discuss», «we'll delete after release». All four — markers of starting on the wrong step.

Ties: sect.5 (Zawinski) — feature creep grows without step 2. sect.29 (Second-System) — attempt to jump to step 3 without 1-2. sect.18 (Hollnagel) — step 5 without 2 is substitution myth. sect.36 (Boy Scout) — operational mode of continuous 2-3 application.

Принцип, восходящий к Аристотелю; в современной инженерии популяризирован Маском. Противопоставляется reasoning by analogy («как делают другие», «как принято»).

Механизм:

1. Сформулируй задачу в терминах физических ограничений и фундаментальной цели, а не в терминах существующих решений.
2. Перечисли все принятые «истины» о задаче. Каждую помечай: физический закон / конвенция / устаревший опыт.
3. Отбрось всё, что не закон физики или фундаментальная цель.
4. Собери решение из оставшегося. Скорее всего, оно будет радикально дешевле и проще.

Канонический пример: аккумуляторы Tesla. Reasoning by analogy: «батареи стоят $600/кВт·ч, такая цена рынка». First principles: «материалы — кобальт, никель, алюминий, графит, сталь. По биржевым ценам — $80/кВт·ч. Остальное — структура производства». Это и есть Idiot Index (sect.44) в применении.

Где не работает:

1. Регуляторные ограничения — они не «конвенция», их нарушение имеет real penalty.
2. Социальная динамика — здесь физических законов нет, и first principles превращается в попытку перепридумать культуру с нуля.
3. Задачи с high time pressure — на reasoning by analogy быстрее, если стоимость ошибки приемлема.

Operational practice: раз в несколько месяцев возвращайся к началу и спрашивай: «если бы мы проектировали это сегодня с нуля, как бы мы сделали?» Это challenge-by-default, защита от drift к посредственности (см. Meadows traps).

Связки: sect.42 (Алгоритм Маска) — first principles это операционная база для шага 1 (Question). sect.44 (Idiot Index) — количественная проверка результата first principles. sect.50 (Local Optimization Trap) — антипод: оптимизация в рамках существующих ограничений вместо их пересмотра.

A principle going back to Aristotle; in modern engineering popularized by Musk. Opposed to reasoning by analogy («as others do», «as is customary»).

The mechanism:

1. Formulate the problem in terms of physical constraints and the fundamental goal, not in terms of existing solutions.
2. List all accepted «truths» about the problem. Tag each: law of physics / convention / outdated experience.
3. Discard everything that isn't a law of physics or a fundamental goal.
4. Build the solution from what remains. It will likely be radically cheaper and simpler.

Canonical example: Tesla batteries. Reasoning by analogy: «batteries cost $600/kWh, that's the market». First principles: «materials — cobalt, nickel, aluminum, graphite, steel. At commodity prices — $80/kWh. The rest is manufacturing structure». This is the Idiot Index (sect.44) in action.

Where it doesn't work:

1. Regulatory constraints — they aren't «convention», breaking them has real penalty.
2. Social dynamics — no physical laws here, and first principles turns into trying to reinvent culture from scratch.
3. High-time-pressure tasks — analogy is faster if error cost is acceptable.

Operational practice: every few months return to the start and ask: «if we designed this today from scratch, how would we do it?» This is challenge-by-default, a defense against drift to mediocrity (see Meadows traps).

Ties: sect.42 (Musk's Algorithm) — first principles is the operational base for step 1 (Question). sect.44 (Idiot Index) — quantitative check on the result of first principles. sect.50 (Local Optimization Trap) — the opposite: optimizing within existing constraints instead of revising them.

Илон Маск, формулировка из Tesla/SpaceX. Если деталь стоит $1000, а сырьё для неё — $100, индекс = 10. Это сигнал, что что-то в цепочке (дизайн, процесс, посредники, шаги) избыточно.

Применение в software engineering — перенос метафоры:

Idiot Index работает не только для физических деталей. В софте: возьми любой output процесса и сравни с минимально необходимыми входами.

— Время от тикета до прода: 14 дней. Минимально необходимое: 2 часа (написать код + тесты + ревью). Idiot Index = 168. Где остальное время? Согласования, переключения контекста, ожидания CI, неудобные tooling.
— Размер deployment package: 200 МБ. Чистый бизнес-код: 5 МБ. Idiot Index = 40. Где остальное? Транзитивные зависимости, dev-tools в проде, дубли библиотек.
— Lines of code на feature: 5000 LoC. Минимально необходимое: 300. Idiot Index = 17. Где остальное? Boilerplate, дубли, защитный код, выросший по культурным причинам.
— Стоимость обработки запроса: $0.10. Чистая работа CPU/memory: $0.001. Idiot Index = 100. Где остальное? Лишние слои (load balancer + API gateway + service mesh + sidecar + service), которые делают то же, что один nginx делал раньше.

Главный механизм: высокий Idiot Index — это не приговор, а гипотеза. Каждый промежуточный слой между сырьём и результатом — подозреваемый. Возможно, слой оправдан (security, observability, compliance). Возможно — нет. Idiot Index заставляет это проверить.

Что НЕ есть Idiot Index:

1. Это не KPI, который надо «оптимизировать вниз». Слепая оптимизация снижает индекс ценой других качеств.
2. Это не сравнение с конкурентами — это сравнение со своим собственным минимумом, который ты определяешь через first principles.
3. Это не аргумент в защиту naked-code без observability/tests/security. Эти слои — не «жир», а часть essential complexity (sect.28).

Связки: sect.43 (First Principles) — определяет знаменатель Idiot Index. sect.42 (Алгоритм Маска) — высокий Idiot Index триггерит шаги 1-2 (question + delete). sect.28 (No Silver Bullet) — отличает essential vs accidental complexity в результатах диагностики.

Elon Musk, formulated at Tesla/SpaceX. If a part costs $1000 but its raw materials cost $100, the index = 10. That's a signal something in the chain (design, process, middlemen, steps) is excessive.

Application in software engineering — extending the metaphor:

The Idiot Index works for more than physical parts. In software: take any process output and compare it to the minimum necessary inputs.

— Time from ticket to prod: 14 days. Minimum necessary: 2 hours (write code + tests + review). Idiot Index = 168. Where's the rest? Approvals, context switches, CI waits, awkward tooling.
— Deployment package size: 200 MB. Pure business code: 5 MB. Idiot Index = 40. Where's the rest? Transitive deps, dev-tools in prod, duplicate libraries.
— Lines of code per feature: 5000 LoC. Minimum necessary: 300. Idiot Index = 17. Where's the rest? Boilerplate, duplicates, defensive code grown for cultural reasons.
— Cost of request processing: $0.10. Pure CPU/memory work: $0.001. Idiot Index = 100. Where's the rest? Excess layers (load balancer + API gateway + service mesh + sidecar + service) doing what one nginx used to do.

The main mechanism: a high Idiot Index isn't a verdict, it's a hypothesis. Every intermediate layer between raw input and output — a suspect. The layer may be justified (security, observability, compliance). Or it may not. Idiot Index forces the question.

What Idiot Index is NOT:

1. Not a KPI to «optimize downward». Blind optimization lowers the index at the cost of other qualities.
2. Not a comparison to competitors — it's a comparison to your own minimum, defined through first principles.
3. Not an argument for naked-code without observability/tests/security. These layers aren't «fat», they're part of essential complexity (sect.28).

Ties: sect.43 (First Principles) — defines the denominator of Idiot Index. sect.42 (Musk's Algorithm) — high Idiot Index triggers steps 1-2 (question + delete). sect.28 (No Silver Bullet) — distinguishes essential vs accidental complexity in diagnostic results.

Цитата Антуана де Сент-Экзюпери из «Terre des hommes» (1939), применённая Эриком Рэймондом в эссе «The Cathedral and the Bazaar» (1997) как урок 13 open-source разработки.

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

Operational test: после любого изменения сравни две метрики до и после — читаемость и размер. Возможные комбинации:

1. Меньше + понятнее. Это правильное направление. Aspire к этому.
2. Меньше + менее понятно. Сжатие в ущерб ясности. Откатить.
3. Больше + понятнее. Допустимо, но это компромисс — попробуй найти вариант 1.
4. Больше + менее понятно. Регрессия. Откатить.

Большинство «улучшений» от среднего инженера — вариант 3 (defensive code, optionality, future-proofing). Большинство улучшений от senior'а — вариант 1.

Связь с минимализмом дизайна: урок 13 — формулировка для эстетики того же, что Алгоритм Маска шаг 2 (Delete) — для процесса. И там, и там — операция уменьшения как первичная, а не вторичная.

Где принцип ломается:

1. Compression vs clarity. Можно довести до того, что код станет «совершенным» по размеру и непонятным. Это не урок 13. «Нечего убрать» означает «нечего убрать без потери ясности».
2. Premature minimization. Применять урок 13 к коду, который ещё не работает, — это yet another форма preliminary optimization. Сначала correctness, потом minimization.
3. Essential complexity. Distributed system inherently имеет components, которые нельзя «убрать» — это не нарушение урока, это physics.

Связки: sect.42 (Алгоритм Маска) — шаг 2 (Delete) в операционном виде. sect.45 — эстетическое обоснование. sect.36 (Boy Scout) — повседневная практика применения. sect.39 (Code Smells) — диагностика того, что можно убрать. sect.30 (Conceptual Integrity) — целостность как побочный продукт минимизации.

A quote from Antoine de Saint-Exupéry in «Terre des hommes» (1939), applied by Eric Raymond in «The Cathedral and the Bazaar» (1997) as lesson 13 of open-source development.

The thesis: code quality and deletion share a vector. When two changes produce the same behavior, the one with less code wins. When two designs solve the same task, the one with fewer moving parts wins.

Operational test: after any change, compare two before/after metrics — readability and size. Possible combinations:

1. Smaller + clearer. Right direction. Aspire to this.
2. Smaller + less clear. Compression at the cost of clarity. Roll back.
3. Bigger + clearer. Acceptable, but a trade-off — try to find option 1.
4. Bigger + less clear. Regression. Roll back.

Most «improvements» from the average engineer are option 3 (defensive code, optionality, future-proofing). Most improvements from a senior are option 1.

Tie to design minimalism: lesson 13 formulates for aesthetics what Musk's Algorithm step 2 (Delete) formulates for process. Both treat reduction as a primary operation, not secondary.

Where the principle breaks:

1. Compression vs clarity. You can push code to be «perfect» by size and unreadable. That's not lesson 13. «Nothing to remove» means «nothing to remove without losing clarity».
2. Premature minimization. Applying lesson 13 to code that doesn't work yet is another form of preliminary optimization. Correctness first, minimization second.
3. Essential complexity. A distributed system inherently has components that can't be «removed» — that's not a violation of the lesson, that's physics.

Ties: sect.42 (Musk's Algorithm) — step 2 (Delete) in operational form. sect.36 (Boy Scout) — everyday practice of application. sect.39 (Code Smells) — diagnostic for what can be removed. sect.30 (Conceptual Integrity) — integrity as a byproduct of minimization.

Эрик Рэймонд, «The Cathedral and the Bazaar», 1997. Урок 14 — наблюдение из истории Unix: grep, sed, awk, pipe создавались для конкретных задач, но оказались строительными блоками для тысяч непредвиденных применений.

Механизм: великий инструмент = ортогональные примитивы + хорошая композиция. Когда примитивы делают одно, а композиция возможна без специальных режимов — пользователи открывают use cases, о которых автор не думал.

Контраст:

— Хороший инструмент: делает то, для чего сделан. Конец истории. Пример: специализированная ERP — отлично решает задачу управления ресурсами; ничего за её пределами.
— Великий инструмент: делает то, для чего сделан, и через композицию решает соседние задачи. Пример: SQL — изначально query language, но используется как ETL-engine, audit log, конфигурационная база, real-time analytics.

Что делает инструмент великим (operational checklist):

1. Один atomic primitive. Инструмент делает ровно одну вещь. grep ищет паттерны. Точка.
2. Композиция через стандартный интерфейс. Pipe (stdin/stdout) или другой uniform protocol позволяет цепочки.
3. Отсутствие глобального состояния. Инструмент — функция, а не агент. Не помнит предыдущие вызовы.
4. Полиморфизм через данные. Inputs и outputs — общий формат (текст, JSON, protobuf). Не bespoke binary.
5. Не предписывает workflow. Не «вы должны использовать так», а «вот примитив, делайте что хотите».

Антипаттерны:

— Feature creep по предсказанию use cases. Автор пытается покрыть все возможные применения через flags и режимы → инструмент становится сложнее и теряет ортогональность.
— Глобальное состояние. «Конфиг» инструмента, который меняет поведение в зависимости от того, как его настроили вчера — убивает композицию.
— Bespoke I/O format. Инструмент принимает только свой формат → нельзя положить в pipe.

Применение к software architecture: микросервисы становятся «великими», когда у них один primitive, общий протокол (HTTP/gRPC), отсутствие shared state и uniform observability. Тогда из них собирают системы, о которых архитектор не думал.

Связки: sect.15 (Postel) — uniform interface, делающий композицию возможной. sect.34 (SOLID/SRP) — atomic primitive. sect.41 (Ports & Adapters) — композиция через стандартные границы. sect.5 (Завински) — feature creep как враг урока 14.

Eric Raymond, «The Cathedral and the Bazaar», 1997. Lesson 14 is an observation from Unix history: grep, sed, awk, pipe were created for specific tasks but turned out to be building blocks for thousands of unanticipated applications.

The mechanism: a great tool = orthogonal primitives + good composition. When primitives do one thing and composition works without special modes — users discover use cases the author never thought of.

Contrast:

— Good tool: does what it was built for. End of story. Example: a specialized ERP — handles resource management; nothing beyond.
— Great tool: does what it was built for and, through composition, solves adjacent problems. Example: SQL — originally a query language, but used as an ETL engine, audit log, configuration database, real-time analytics.

What makes a tool great (operational checklist):

1. One atomic primitive. The tool does exactly one thing. grep finds patterns. Period.
2. Composition via standard interface. Pipe (stdin/stdout) or another uniform protocol allows chains.
3. No global state. The tool is a function, not an agent. Doesn't remember previous calls.
4. Polymorphism via data. Inputs and outputs — a common format (text, JSON, protobuf). Not a bespoke binary.
5. Doesn't prescribe workflow. Not «you must use it this way», but «here's the primitive, do what you want».

Anti-patterns:

— Feature creep based on predicted use cases. The author tries to cover all possible applications through flags and modes → tool grows complex and loses orthogonality.
— Global state. A «config» that changes behavior based on yesterday's setup — kills composition.
— Bespoke I/O format. Tool accepts only its own format → can't pipe it.

Application to software architecture: microservices become «great» when they have one primitive, a common protocol (HTTP/gRPC), no shared state, and uniform observability. Then they're assembled into systems the architect never imagined.

Ties: sect.15 (Postel) — uniform interface enabling composition. sect.34 (SOLID/SRP) — atomic primitive. sect.41 (Ports & Adapters) — composition through standard boundaries. sect.5 (Zawinski) — feature creep as enemy of lesson 14.

Стив Джобс, WWDC 1997. Часто перефразируется как «сначала определите проблему — технологии найдутся». Это операционный принцип Apple-эры Джобса, противопоставленный engineering-driven продуктам, где стек выбирается раньше понимания пользователя.

Канонический алгоритм:

1. Проблема. Сформулируй конкретную пользовательскую боль и метрику успеха в её терминах. «Пользователь тратит 5 минут, чтобы найти нужный файл» — это проблема. «Нужна search engine» — это уже решение.
2. Валидация. Подтверди ценность интервью, прототипами, данными. MVP, эксперименты. Если боль не подтверждается — не строй.
3. Технология. Выбери самое простое решение под confirmed pain. Учитывай scale, risks, timelines.

Что такое solutionism: влюблённость в решение в обход проблемы. Симптомы:

— «Давайте применим LLM к этому процессу» — без явной формулировки, что в процессе сейчас болит.
— «Перепишем на Rust» — без метрики, которая улучшится.
— «Микросервисы» — потому что монолит «устарел», а не потому что есть конкретное ограничение, которое монолит блокирует.
— «Сделаем мобильное приложение» — потому что у конкурентов есть, не потому что пользователи спрашивают.

Почему инженеры особенно склонны к solutionism: технологии — то, что они любят и понимают. Проблемы пользователей — менее знакомая территория. Естественное искушение — начать со знакомого. Это и есть когнитивная ловушка, против которой работает Problem-First.

Границы принципа:

1. R&D-проекты. «Сначала проблема» не работает для прорывных исследований, где ты сам не знаешь, что возможно. Иногда технология открывает класс задач, который раньше не существовал.
2. Инфраструктура. Часть стека (логи, метрики, deployment pipeline) не имеет «пользовательской проблемы» в традиционном смысле — её customer это твои собственные инженеры.

End-to-end переосмысление (Эллисон): «Нельзя модернизировать только ERP. Надо обновлять весь процесс end-to-end». Problem-First на макро-уровне — это переформулирование цепочки целиком, а не оптимизация одного звена.

Связки: sect.5 (Завински) — feature creep это solutionism в action. sect.42 (Алгоритм Маска) — шаг 1 (Question requirements) совпадает с этим принципом. sect.50 (Local Optimization Trap) — solutionism часто проявляется как локальная оптимизация. sect.43 (First Principles) — методологически совпадает: начать с фундамента (проблема), не со стека.

Steve Jobs, WWDC 1997. Often paraphrased as «first define the problem, the technology will follow». An operational principle of Jobs-era Apple, opposed to engineering-driven products where the stack is chosen before user understanding.

The canonical algorithm:

1. Problem. Formulate the specific user pain and a success metric in its terms. «The user spends 5 minutes finding the right file» is a problem. «We need a search engine» is already a solution.
2. Validation. Confirm value through interviews, prototypes, data. MVP, experiments. If the pain isn't confirmed — don't build.
3. Technology. Pick the simplest solution for the confirmed pain. Consider scale, risks, timelines.

What is solutionism: falling in love with a solution while bypassing the problem. Symptoms:

— «Let's apply LLMs to this process» — without explicitly formulating what hurts in the process now.
— «Let's rewrite in Rust» — without a metric that will improve.
— «Microservices» — because the monolith is «outdated», not because of a specific limitation the monolith is blocking.
— «Build a mobile app» — because competitors have one, not because users ask.

Why engineers are especially prone to solutionism: technologies are what they love and understand. User problems are less familiar territory. The natural temptation is to start with the familiar. That's the cognitive trap Problem-First counters.

Boundaries of the principle:

1. R&D projects. «Problem first» doesn't work for breakthrough research where you don't yet know what's possible. Sometimes technology opens a class of problems that didn't exist before.
2. Infrastructure. Part of the stack (logs, metrics, deployment pipeline) has no «user problem» in the traditional sense — its customer is your own engineers.

End-to-end reframing (Ellison): «You can't modernize just ERP. You have to update the entire end-to-end process». Problem-First at macro scale — reformulating the entire chain, not optimizing one link.

Ties: sect.5 (Zawinski) — feature creep is solutionism in action. sect.42 (Musk's Algorithm) — step 1 (Question requirements) aligns with this principle. sect.50 (Local Optimization Trap) — solutionism often shows up as local optimization. sect.43 (First Principles) — methodologically aligned: start from foundation (problem), not stack.

Источник — Robert C. Martin, «Чистый Agile». Тезис фундаментальный: жёсткое железо тоже могло бы реализовывать те же функции, что и софт. Софт существует как отдельная категория именно потому, что меняется быстрее и дешевле.

Следствие: сопротивление изменению требований — это не защита проекта, а самопровозглашение, что архитектура неисправна. «Эти изменения дают нам работу и кормят нас. Наша работа — мириться с изменениями требований и находить решения, которые будут относительно недороги».

Операционное определение качественной архитектуры: стоимость изменения должна быть пропорциональна масштабу запроса, а не масштабу хрупкости системы. Если бизнес просит «изменить копейку на цифре» и это занимает 3 спринта — архитектура сломана, не требование.

Главные источники сопротивления изменениям:

— Tight coupling (нарушение SOLID, sect.34): изменение в одном месте требует правок в десяти.
— Anemic abstractions (sect.41 Ports & Adapters): анемичный port вместо domain-level операции.
— Test-fragility: любое изменение валит десятки тестов, потому что они проверяют реализацию, а не поведение.
— Big-bang releases: страх изменений из-за того, что каждый релиз — событие.
— Lack of TDD/CI: нет защитной сетки, изменения = страх.

Инверсия мышления: традиционная мысль — «требования меняются, надо это контролировать (заморозить, утвердить, change request)». Правильная мысль — «требования будут меняться всегда, надо строить так, чтобы это было дёшево». Это разворот цели всей профессии.

Что это меняет в практике:

1. Архитектура оценивается по cost-of-change. Не по красоте, не по theoretical purity. По времени от «бизнес попросил» до «бизнес видит в проде».
2. Лучшая архитектура — та, которую легко переделать. Не «правильная», а адаптивная.
3. Изменения — основной use case системы, не исключение. Проектируй для них с первого дня.

Связки: sect.23 (Lehman) — software must continually evolve. sect.16 (Beck's 3X) — фаза Expand именно про адаптацию к меняющимся требованиям. sect.34 (SOLID/OCP) — Open for extension — структурная формулировка той же идеи. sect.40 (StranglerFig) — стратегия adaptation к большим изменениям.

Source — Robert C. Martin, «Clean Agile». The thesis is fundamental: rigid hardware could realize the same functions as software. Software exists as a separate category precisely because it changes faster and cheaper.

Consequence: resistance to changing requirements isn't project defense, it's a self-declaration that architecture is broken. «These changes give us work and feed us. Our job is to accommodate requirement changes and find solutions that are relatively cheap».

Operational definition of good architecture: change cost should be proportional to the scope of the request, not to system fragility. If the business asks «change a penny on a digit» and it takes 3 sprints — architecture is broken, not the requirement.

Main sources of change resistance:

— Tight coupling (SOLID violation, sect.34): a change in one place requires edits in ten.
— Anemic abstractions (sect.41 Ports & Adapters): anemic port instead of a domain-level operation.
— Test fragility: any change breaks dozens of tests because they verify implementation, not behavior.
— Big-bang releases: fear of change because every release is an event.
— Lack of TDD/CI: no safety net, changes = fear.

Inversion of thinking: traditional thought — «requirements change, must control it (freeze, sign off, change request)». Correct thought — «requirements will always change, build to make that cheap». A reversal of the profession's goal.

What this changes in practice:

1. Architecture is evaluated by cost-of-change. Not beauty, not theoretical purity. By the time from «business asked» to «business sees in prod».
2. The best architecture is the one easy to redo. Not «correct» — adaptive.
3. Changes are the system's main use case, not the exception. Design for them from day one.

Ties: sect.23 (Lehman) — software must continually evolve. sect.16 (Beck's 3X) — the Expand phase is exactly about adapting to changing requirements. sect.34 (SOLID/OCP) — Open for extension is the structural formulation of the same idea. sect.40 (StranglerFig) — strategy for adaptation to large changes.

Кент Бек, главный тезис книги «Tidy First?». Цитируется в Mark Seemann «Код который умещается в голове». Главное утверждение: причина деградации софта — не сложность задачи, а несоответствие сложности фрагмента ёмкости рабочей памяти инженера.

Биологический предел: рабочая память человека удерживает ~7 ± 2 chunks одновременно (Miller 1956). На сложных задачах — меньше, обычно 4-5. Этот предел не растёт с опытом — растёт только размер каждого chunk'а через chunking.

Канонические признаки превышения предела:

1. «Я начинаю терять контекст в этой функции» — функция длиннее ~50 строк.
2. «Не помню, что эта переменная значит» — слишком много state в одной области видимости.
3. «Боюсь менять, могу сломать что-то ещё» — слишком много связей у компонента.
4. «Нужен diagramming session, чтобы понять flow» — control flow не помещается в голову линейно.
5. «Только Иван знает, как это работает» — компонент превысил head-size одного человека.

Operational rule: когда хоть один признак сработал — это сигнал не к более внимательному изучению, а к фрагментации. Делишь до тех пор, пока каждая часть не помещается в голову отдельно. Связи между частями делаешь явными и узкими.

Связь с другими принципами:

— SOLID/SRP (sect.34): SRP — это правило «один reason to change», head-size — это правило «один chunk should fit». Часто совпадают.
— Conceptual Integrity (sect.30): целостный концепт легче помещается в голову, чем разрозненная коллекция.
— Code Smells (sect.39): Long Method, Large Class — это, в первую очередь, нарушения head-size, не абстрактные «нечистоты».
— Closure Property (FP): композиция функций, каждая из которых помещается в голову, даёт систему, которая помещается в голову как набор инвариантов.

Что отличает head-size от просто «делай поменьше»:

Head-size — это не про абсолютный размер, а про cognitive fit. Функция в 30 строк может не помещаться, если в ней 6 переменных и 4 ветвления. Функция в 80 строк — может помещаться, если это линейный pipeline с очевидной структурой. Метрика — не LoC, а количество одновременно удерживаемых «движущихся частей».

В контексте AI-генерации кода: LLM не имеет head-size limit. Она генерирует функции на 200 строк, потому что может. Это и есть главный риск AI-кода: он работает, но не помещается в голову ни одного человека, которому придётся его поддерживать. Head-size — основной критерий приёмки AI-генерации.

Связки: sect.30 (Conceptual Integrity), sect.34 (SOLID), sect.39 (Code Smells), sect.27 (Brooks ×9 — exponential growth of communication beyond head size).

Kent Beck, the central thesis of «Tidy First?». Cited in Mark Seemann's «Code That Fits in Your Head». Main claim: software degradation isn't caused by task complexity, but by mismatch between fragment complexity and the engineer's working memory capacity.

Biological limit: human working memory holds ~7 ± 2 chunks simultaneously (Miller 1956). For complex tasks — fewer, usually 4-5. This limit doesn't grow with experience — only the size of each chunk grows, through chunking.

Canonical signs of exceeding the limit:

1. «I'm losing context in this function» — function longer than ~50 lines.
2. «Don't remember what this variable means» — too much state in one scope.
3. «Afraid to change, might break something else» — too many connections in the component.
4. «Need a diagramming session to understand flow» — control flow doesn't fit linearly in head.
5. «Only Ivan knows how this works» — component exceeded one person's head-size.

Operational rule: when even one sign fires — it's not a signal for more careful study, but for fragmentation. Split until each part fits in a head separately. Make connections between parts explicit and narrow.

Ties to other principles:

— SOLID/SRP (sect.34): SRP is the «one reason to change» rule, head-size is the «one chunk should fit» rule. Often coincide.
— Conceptual Integrity (sect.30): a coherent concept fits in a head more easily than a fragmented collection.
— Code Smells (sect.39): Long Method, Large Class — primarily head-size violations, not abstract «uncleanness».
— Closure Property (FP): composition of functions, each fitting in a head, gives a system fitting in a head as a set of invariants.

What distinguishes head-size from «just make smaller»:

Head-size isn't about absolute size, it's about cognitive fit. A 30-line function may not fit if it has 6 variables and 4 branches. An 80-line function may fit if it's a linear pipeline with obvious structure. The metric isn't LoC, it's the count of simultaneously held «moving parts».

In the context of AI-generated code: LLMs have no head-size limit. They generate 200-line functions because they can. That's the main risk of AI code: it works, but doesn't fit in anyone's head who'll have to maintain it. Head-size is the primary acceptance criterion for AI generation.

Ties: sect.30 (Conceptual Integrity), sect.34 (SOLID), sect.39 (Code Smells), sect.27 (Brooks ×9 — exponential growth of communication beyond head size).

Системное наблюдение, формализованное в operations research и системном мышлении (Donella Meadows). В software engineering проявляется как структурная ошибка: каждая команда оптимизирует свой компонент, при этом сумма локальных оптимизаций может быть направлена против цели всей системы.

Канонические примеры в software:

1. Frontend оптимизирует latency своей страницы кэшированием, что инвалидирует кэш backend и увеличивает общую latency.
2. Database team оптимизирует write throughput снимая constraints, что увеличивает количество inconsistent records и нагрузку на operational team.
3. Security team усиливает auth в каждом сервисе, что увеличивает round-trip latency и заставляет product team disable security features в production.
4. Каждая команда переходит на свой best stack, что суммарно создаёт polyglot infrastructure без operational knowledge.
5. SRE оптимизирует MTTR через automation runbooks, что лишает junior'ов опыта incident response.

Структурная причина: компонент оптимизируется по локальной метрике, которая является прокси для глобальной цели. Под давлением оптимизации прокси отделяется от цели (Goodhart, sect.9), и команда чемпионит «успех» по метрике, при том что система деградирует.

Признаки локальной оптимизации:

— Команда A показывает зелёные дашборды; команда B жалуется на ухудшение.
— Каждый отдел рапортует успех, но общая ситуация хуже прошлого квартала.
— Изменения в одном сервисе требуют compensating changes в трёх соседних.
— Победители KPI собираются в отделе, который наименее важен для customer value.

Antidote — system-level thinking:

1. Метрики на уровне системы важнее метрик уровня компонента. End-to-end customer-facing latency, не average response time каждого сервиса.
2. Team boundaries следуют domain boundaries (Conway, sect.3) — оптимизация в команде = оптимизация в domain, что вероятнее совпадает с глобальным улучшением.
3. Прокси-метрики уходят, system-metrics остаются. Goodhart-resistant дизайн KPI: GSM framework (Goals→Signals→Metrics, Google), не прямые метрики.
4. Перед оптимизацией компонента — проверь его влияние на neighboring components. Если нельзя — оптимизация преждевременна.

Особенный случай: микросервисная архитектура. Микросервисы дают командам автономию, что усиливает риск локальной оптимизации. Antidote: cross-team SLAs, observability на уровне traces, regular system-level retros.

Связки: sect.3 (Conway), sect.9 (Goodhart), sect.27 (Brooks ×9), Meadows traps (drift, escalation).

A systems observation formalized in operations research and systems thinking (Donella Meadows). In software engineering, it manifests as a structural error: each team optimizes its component, while the vector sum of local optimizations may point against the whole system's goal.

Canonical examples in software:

1. Frontend optimizes its page latency through caching, which invalidates backend cache and increases overall latency.
2. Database team optimizes write throughput by removing constraints, which increases inconsistent records and load on the operational team.
3. Security team strengthens auth in every service, increasing round-trip latency and forcing the product team to disable security features in production.
4. Each team switches to its own best stack, creating polyglot infrastructure without operational knowledge across all of it.
5. SRE optimizes MTTR through automation runbooks, depriving juniors of incident response experience.

Structural cause: a component is optimized against a local metric that proxies a global goal. Under optimization pressure, the proxy separates from the goal (Goodhart, sect.9), and the team celebrates «success» by the metric, while the system degrades.

Signs of local optimization:

— Team A shows green dashboards; team B complains of degradation.
— Every department reports success, but the overall situation is worse than last quarter.
— Changes in one service require compensating changes in three neighbors.
— KPI winners cluster in the department least relevant to customer value.

Antidote — system-level thinking:

1. System-level metrics outrank component-level metrics. End-to-end customer-facing latency, not average response time per service.
2. Team boundaries follow domain boundaries (Conway, sect.3).
3. Proxy metrics fade, system metrics remain. Goodhart-resistant KPI design.
4. Before optimizing a component — verify its impact on neighboring components. If you can't — optimization is premature.

Special case: microservice architecture. Microservices give teams autonomy, which amplifies the local-optimization risk. Antidote: cross-team SLAs, trace-level observability, regular system-level retros.

Ties: sect.3 (Conway), sect.9 (Goodhart), sect.27 (Brooks ×9), Meadows traps (drift, escalation).

Это шаг 5 Алгоритма Маска (sect.42) в форме отдельного закона. Формулировка важна сама по себе, потому что нарушение этого порядка — самая распространённая ошибка в инженерных командах, обладающих хорошим тулингом.

Механизм деградации:

1. Процесс работает плохо — много ручных шагов, неявные дублирования, частые ошибки.
2. Команда видит «много ручной работы» как проблему. Решение: автоматизация.
3. Скрипт пишется поверх существующего процесса, копируя все его шаги.
4. Результат: процесс выполняется в 10 раз быстрее, ошибки тоже происходят в 10 раз быстрее.
5. Процесс закреплён в коде → теперь его сложнее изменить, чем раньше.
6. Через год: процесс изменился, скрипт устарел, никто не понимает, что он делает; параллельно появилась новая ручная работа поверх автоматизации.

Тест перед автоматизацией:

1. Можешь ли убрать половину шагов? Если да — убери, потом автоматизируй оставшиеся.
2. Понимает ли каждый шаг конкретный человек? Если шаг существует «по историческим причинам» — не автоматизируй, выясни.
3. Что произойдёт, если скрипт ошибётся 1000 раз быстрее? Если ответ «катастрофа» — добавь rollback, dry-run, idempotency перед автоматизацией.
4. Сколько раз в году выполняется процесс? Если <10 — стоимость автоматизации > стоимости ручной работы; не автоматизируй.
5. Меняется ли процесс? Если да — автоматизация будет ломаться при каждом изменении; сначала стабилизируй.

Когда автоматизация оправдана:

1. Процесс stable (тестировался руками много раз).
2. Минимизирован до essential шагов.
3. Каждый шаг понят и оправдан.
4. Высокая частота выполнения.
5. Есть способ откатить, dry-run, наблюдать поведение.

В контексте CI/CD: страх «давайте автоматизируем deployment» часто закрепляет хаотичный процесс деплоя в pipeline. Правильный порядок: 1) deployment должен быть выполним руками за <10 минут с понятной checklist; 2) только после — автоматизировать; 3) keep manual fallback навсегда.

В контексте AI agents: применение agent automation к плохо спроектированному процессу — это automating chaos с amplification. Agent не видит, что процесс плох; он выполняет его быстрее. Сначала редизайн процесса под agent, потом автоматизация.

Связки: sect.42, sect.18 (Hollnagel — substitution myth), sect.50 (Local Optimization Trap), sect.52 (Don't Optimize the Unnecessary).

This is step 5 of Musk's Algorithm (sect.42) as a standalone law. The formulation matters on its own because breaking this order is the most common mistake in engineering teams with good tooling.

The degradation mechanism:

1. Process works poorly — many manual steps, implicit duplications, frequent errors.
2. The team sees «lots of manual work» as the problem. Solution: automation.
3. A script is written on top of the existing process, copying all its steps.
4. Result: the process runs 10× faster; errors also happen 10× faster.
5. The process is locked into code → now harder to change than before.
6. A year later: process has changed, script is stale, no one understands what it does; new manual work has appeared on top of the automation.

Test before automating:

1. Can you remove half the steps? If yes — remove them, then automate the rest.
2. Does every step have an owner who understands it? If a step exists «for historical reasons» — don't automate, investigate.
3. What happens if the script errors 1000× faster? If the answer is «catastrophe» — add rollback, dry-run, idempotency before automation.
4. How often per year does the process run? If <10 — automation cost > manual cost; don't automate.
5. Does the process change? If yes — automation will break on every change; stabilize first.

When automation is justified:

1. Process is stable (tested by hand many times).
2. Minimized to essential steps.
3. Each step understood and justified.
4. High execution frequency.
5. There's a way to rollback, dry-run, observe behavior.

In CI/CD context: the impulse «let's automate deployment» often locks a chaotic deploy process into a pipeline. Correct order: 1) deployment must be executable manually in <10 min with a clear checklist; 2) only then — automate; 3) keep manual fallback forever.

In AI agents context: applying agent automation to a poorly designed process is automating chaos with amplification. The agent doesn't see that the process is bad; it executes it faster. First redesign the process for the agent, then automate.

Ties: sect.42, sect.18 (Hollnagel — substitution myth), sect.50 (Local Optimization Trap), sect.52 (Don't Optimize the Unnecessary).

Илон Маск, формулировка из engineering process. Это шаг 3 Алгоритма (sect.42) в самостоятельной форме. Тезис обращён в первую очередь к опытным инженерам — у них больше soup в инструменте оптимизации, и они быстрее уходят в локальный максимум, не остановившись на «а должно ли это существовать?».

Психологический механизм: оптимизация — приятная и видимая работа. Удаление — невидимая и пугающая. У инженера есть навык оптимизации, и применяя его, он чувствует свою ценность. Спрашивать «а зачем это вообще?» — означает признать, что часть проделанной работы была лишней. Это болезненно, и поэтому редко.

Канонические случаи:

1. Оптимизация query, к которому не должно быть запросов. Endpoint, никому не нужный, оптимизируется, потому что появляется в slow query logs.
2. Оптимизация деплоя сервиса, который надо merge с другим. Команда тратит спринты на ускорение build pipeline сервиса A, при том что 80% функциональности дублирует сервис B.
3. Оптимизация cron job, который запускается раз в год. Был неэффективен, ускорили в 10 раз. Сэкономили 30 минут раз в год. Стоимость работы — 2 недели инженера.
4. Оптимизация документации устаревшего API. Команда улучшает примеры, форматирование, поиск. API будет deprecated через квартал.
5. Оптимизация feature flag, который должен быть удалён. Toggle существует 2 года, у него три bug fix'а, никто не помнит, зачем он.

Признаки того, что ты оптимизируешь лишнее:

— Тебе пришлось разбираться, зачем нужна эта функциональность, прежде чем оптимизировать.
— Метрика, которую улучшаешь, никем не отслеживается напрямую (нет alerting, нет dashboard'а).
— После оптимизации никто не заметит улучшения, кроме тебя.
— Аргументация требует ссылок на гипотетические будущие случаи.
— «Когда-нибудь это пригодится» — главное обоснование.

Пятисекундный тест перед оптимизацией:

1. Кто конкретно почувствует улучшение?
2. Какое решение этот кто-то сможет принять, которое не мог принять без улучшения?
3. Если бы я строил это сегодня с нуля — было ли бы это вообще?

Если ответ на любой из трёх — расплывчатый, оптимизация преждевременна. Сначала вопросы 1-2 Алгоритма Маска (sect.42).

Связь с AI-кодом: AI охотно оптимизирует то, что попросишь — без понимания, должно ли это существовать. Применение AI к «улучши этот код» без предварительного «нужен ли этот код вообще» — automation of misallocation.

Связки: sect.42 (Алгоритм Маска — корень), sect.43 (First Principles), sect.50 (Local Optimization Trap), sect.51 (Automating Chaos), sect.5 (Завински).

Elon Musk, formulation from the engineering process. This is step 3 of the Algorithm (sect.42) in standalone form. The thesis is aimed at experienced engineers first — they have more horsepower in the optimization tool and go deeper into the local maximum without stopping at «should this exist?»

Psychological mechanism: optimization is pleasant and visible work. Deletion is invisible and scary. An engineer has the skill of optimization, and using it feels valuable. Asking «why this at all?» means admitting some past work was wasted. That hurts, and is rarely done.

Canonical cases:

1. Optimizing a query that shouldn't be queried. An endpoint nobody needs gets optimized because it appears in slow query logs.
2. Optimizing the deploy of a service that should be merged with another. Team spends sprints accelerating service A's build pipeline while 80% of its functionality duplicates service B.
3. Optimizing a cron job that runs once a year. It was inefficient; sped up 10×. Saved 30 minutes once a year. Cost — 2 engineer-weeks.
4. Optimizing docs for a deprecated API. Team improves examples, formatting, search. The API will be deprecated next quarter.
5. Optimizing a feature flag that should be deleted. Toggle has existed for 2 years, three bug fixes, no one remembers why.

Signs you're optimizing the unnecessary:

— You had to figure out why the functionality exists before optimizing.
— The metric you're improving isn't tracked by anyone (no alerting, no dashboard).
— After optimization, no one notices the improvement except you.
— Justification requires references to hypothetical future cases.
— «It'll come in handy someday» — main rationale.

Five-second test before optimization:

1. Who specifically will feel the improvement?
2. What decision can that someone now make that they couldn't before?
3. If I were building this from scratch today — would it exist at all?

If any of the three is vague — optimization is premature. First, questions 1-2 of Musk's Algorithm (sect.42).

Ties to AI code: AI eagerly optimizes whatever you ask — without understanding whether it should exist. Applying AI to «improve this code» without first «is this code needed at all» — automation of misallocation.

Ties: sect.42 (Musk's Algorithm — root), sect.43 (First Principles), sect.50 (Local Optimization Trap), sect.51 (Automating Chaos), sect.5 (Zawinski).

Steve Vinter, бывший engineering director Google. Концепция servant leadership ранее формализована Robert Greenleaf (1970). В software engineering особенно применима, потому что выходная функция инженера — результат глубокой focus-работы, которую менеджер физически не может выполнить сам.

Операционные обязанности servant leader:

1. Убрать блокеры. Доступы, согласования, отсутствие нужных людей в комнате — это не «инженер должен сам разобраться», это manager-failure.
2. Защитить от шума. Random ping'и от других команд, meetings без agenda, политические разборки — менеджер абсорбирует это, чтобы инженеры работали.
3. Обеспечить tooling и environment. Медленный CI, плохие dashboards, отсутствие staging — это manager budget priorities, не «техдолг команды».
4. Дать context, не таски. «Вот цель квартала, вот ограничения» — а не «делайте X, Y, Z». Инженер сам выберет правильное X.
5. Признать ошибки публично. Менеджер берёт ответственность за провалы команды, делегирует кредит за успехи.

Антипод — command-and-control: менеджер раздаёт задачи, контролирует исполнение, измеряет в часах присутствия и количестве commits. В software engineering это даёт измеримые metrics на короткой дистанции и катастрофу на долгой.

Почему модель работает именно в software:

— Работа инженера невозможно проверить через присутствие. Результат — это качество решений, видимое только через месяцы.
— Инженер обладает уникальным контекстом своего компонента; менеджер не может «принять решение за него».
— Главное узкое место — focus time. Менеджер, занимающий focus time инженера meetings'ами, разрушает выходную функцию.
— Текучка дорогая. Один уходящий senior — это полгода ramp-up для замены. Менеджер, удерживающий senior'ов через служение их работе, экономически выгоден.

Что НЕ есть servant leadership:

1. Не «менеджер делает всё, что хочет инженер». Servant — не sycophant. Hard decisions делает менеджер.
2. Не отсутствие feedback. Прямая, регулярная обратная связь — часть служения, не противоположность ему.
3. Не «нет иерархии». Иерархия есть, но направление service flow — вниз, не вверх.

Связки: sect.21 (HOP — system, not person, fails), sect.7 (Price's Law — protect the productive few), sect.27 (Brooks ×9 — managing communication overhead), sect.54 (Go to the Source — наблюдение там, где работа происходит).

Steve Vinter, former engineering director at Google. The servant leadership concept was earlier formalized by Robert Greenleaf (1970). It's especially applicable in software engineering, because an engineer's output function is the result of deep focus work that a manager physically can't perform themselves.

Operational duties of a servant leader:

1. Remove blockers. Access, approvals, missing people in the room — that's not «the engineer should figure it out», that's manager failure.
2. Shield from noise. Random pings from other teams, meetings without agenda, political squabbles — the manager absorbs these so engineers can work.
3. Provide tooling and environment. Slow CI, bad dashboards, no staging — these are manager budget priorities, not «team's tech debt».
4. Give context, not tasks. «Here's the quarter goal, here are constraints» — not «do X, Y, Z». The engineer will pick the right X.
5. Own mistakes publicly. The manager takes responsibility for team failures, delegates credit for successes.

Opposite — command-and-control: the manager assigns tasks, controls execution, measures in hours present and commits count. In software engineering, this yields measurable short-term metrics and long-term catastrophe.

Why the model works in software specifically:

— Engineer's work can't be verified through presence. The result is decision quality, visible only over months.
— The engineer has unique context for their component; the manager can't «make the decision for them».
— The main bottleneck is focus time. A manager occupying focus time with meetings destroys the output function.
— Attrition is expensive. One leaving senior is half a year of ramp-up for a replacement. A manager retaining seniors by serving their work is economically advantageous.

What servant leadership is NOT:

1. Not «manager does everything the engineer wants». Servant ≠ sycophant. Hard decisions are still the manager's.
2. Not absence of feedback. Direct, regular feedback is part of service, not its opposite.
3. Not «no hierarchy». Hierarchy exists, but the service flow direction is downward, not upward.

Ties: sect.21 (HOP — system, not person, fails), sect.7 (Price's Law — protect the productive few), sect.27 (Brooks ×9 — managing communication overhead), sect.54 (Go to the Source).

Илон Маск, многократно подчёркивается в Tesla/SpaceX. Канонический пример: «Я хочу говорить не с твоим менеджером, я хочу говорить с инженером, который писал этот код вчера». Японская manufacturing-аналогия — genchi genbutsu («иди и смотри»).

Механизм искажения managerial reports:

1. Инженер знает: «деплой ломается в 30% случаев, я обхожу руками».
2. Tech lead в отчёте: «деплой нестабилен, добавили manual step».
3. Менеджер в свод: «pipeline reliability is acceptable, team has workarounds».
4. Директор на review: «всё работает». Принимает решение не инвестировать в pipeline.
5. Через 6 месяцев — incident, потому что workaround сломался под нагрузкой.

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

Практика go-to-the-source:

1. Регулярные skip-level разговоры (sect.59). Топ-менеджер раз в квартал говорит с инженерами через 2 уровня вниз.
2. Read the code (Маск). Менеджер инженерной команды иногда читает фактический код — не code reviews, а production code на критическом пути.
3. Walk the floor. В hybrid teams: садиться рядом с инженером и смотреть, как работает на самом деле.
4. Постоянные «глупые» вопросы. «А что произойдёт, если эта очередь переполнится?» — вопрос, который раскрывает реальные failure modes.
5. Incidents как обязательное reading. Postmortems на инженерном уровне — для менеджеров; не RCAs в исполнении менеджеров.

Что мешает go-to-source:

— Tech lead интерпретирует «обход» как угрозу. «Если босс говорит с моим инженером, значит, мне не доверяют».
— Большие компании boundaries. Юридические/HR причины формализуют коммуникацию через line manager.
— Сами инженеры не уверены. Привыкли, что «правду» говорит менеджер.
— Менеджеры не понимают тех. контекст. Не могут задать right questions при разговоре с инженером.

Связки: sect.21 (HOP — work-as-done ≠ work-as-imagined; ровно тот же тезис), sect.55 (Personal Accountability — у каждого требования есть автор), sect.57 (Manager как судья), sect.59 (Skip-level), sect.66 (Эго в продукте — менеджер, не идущий к источнику, действует по интуиции).

Elon Musk, repeatedly emphasized at Tesla/SpaceX. Canonical example: «I don't want to talk to your manager, I want to talk to the engineer who wrote this code yesterday». Japanese manufacturing analogue — genchi genbutsu («go and see»).

Distortion mechanism of managerial reports:

1. Engineer knows: «deploy breaks 30% of the time, I work around it by hand».
2. Tech lead in report: «deploy is unstable, added manual step».
3. Manager in summary: «pipeline reliability is acceptable, team has workarounds».
4. Director at review: «all working». Decides not to invest in the pipeline.
5. Six months later — incident, because the workaround broke under load.

At each level, information loses specificity and gains political coloring — because each link in the chain doesn't want to appear as the source of the problem.

Go-to-the-source practice:

1. Regular skip-level conversations (sect.59). Top manager once a quarter talks with engineers two levels down.
2. Read the code (Musk). Engineering manager occasionally reads actual code — not code reviews, production code on the critical path.
3. Walk the floor. In hybrid teams: sit next to the engineer and watch how things actually work.
4. Persistent «stupid» questions. «What happens if this queue overflows?» — a question that reveals real failure modes.
5. Incidents as mandatory reading. Engineer-level postmortems for managers; not RCAs in managerial prose.

What blocks go-to-source:

— Tech lead interprets «bypass» as a threat. «If the boss talks to my engineer, they don't trust me».
— Big company boundaries. Legal/HR reasons formalize communication through line managers.
— Engineers themselves aren't sure. Used to «truth» being told by the manager.
— Managers don't understand technical context. Can't ask the right questions when talking to an engineer.

Ties: sect.21 (HOP — work-as-done ≠ work-as-imagined; the exact same thesis), sect.55 (Personal Accountability), sect.57 (Manager as Judge), sect.59 (Skip-level), sect.66 (Ego in Product).

Илон Маск, шаг 1 алгоритма (sect.42) в развёрнутой форме. Тезис: коллективная ответственность за требование = отсутствие ответственности. Если на вопрос «кто это требует?» ответ «security team» или «product», требование уже сломано в источнике.

Тест «у каждого требования есть человек»:

1. Возьми любое требование из спецификации.
2. Спроси: «Кто конкретно это попросил?» — нужно имя.
3. Иди к этому человеку и спроси: «Почему?»
4. Если у него нет ясного ответа — требование удаляется. Если есть — оно становится его требованием с его именем.
5. Если позже требование окажется ошибкой — у него есть имя, не «отдел».

Почему диффузия ответственности — самый дорогой anti-pattern:

— Нет одного человека, способного отозвать требование. Чтобы убрать, надо «согласовать с отделом», что в практике означает not happens.
— Защитный over-engineering. Когда никто не отвечает за требование, инженер боится его не выполнить полностью; покрывает edge cases, которые никто не просил.
— Невозможен анализ ошибок. Если плохое требование привело к падению — кого учить? Никого. Ошибка повторится.
— Замораживание организации. Все требования живут вечно, потому что нет владельца, чтобы их отменить.

Operational mechanics:

1. Каждый ticket / требование / constraint должен иметь named owner. Не команда, не отдел — Иван Петров.
2. Owner защищает требование на любом review. Если он не может его защитить — требование удаляется.
3. Owner может удалить своё требование без согласований. Это и есть проверка, что у него есть власть, соразмерная ответственности.
4. Меняется owner — меняется требование. Когда человек уходит из команды, его требования пересматриваются, не наследуются.

В контексте AI-кода: AI охотно реализует то, что попросишь, не спрашивая «кто это требует и зачем». Применение AI без явного human owner для каждого требования — это amplification отсутствия accountability.

Связки: sect.42 (Алгоритм Маска — шаг 1), sect.21 (HOP — accountability на уровне системы), sect.56 (DRI — institutionalized version того же принципа в Apple), sect.65 (Hope is not a strategy — без owner надежда становится планом).

Elon Musk, step 1 of the algorithm (sect.42) in expanded form. Thesis: collective responsibility for a requirement = no responsibility. If the answer to «who requests this?» is «security team» or «product», the requirement is already broken at source.

Test «every requirement has a person»:

1. Take any requirement from the spec.
2. Ask: «Who specifically asked for this?» — need a name.
3. Go to that person and ask: «Why?»
4. If they have no clear answer — the requirement is deleted. If they do — it becomes their requirement with their name.
5. If the requirement later turns out to be wrong — they have a name, not «the department».

Why accountability diffusion is the most expensive anti-pattern:

— No single person able to withdraw the requirement. Removing it means «coordinate with the department», which in practice means not happens.
— Defensive over-engineering. When no one owns a requirement, the engineer fears not fulfilling it completely; covers edge cases nobody asked for.
— Error analysis impossible. If a bad requirement caused a failure — who do you teach? Nobody. The error repeats.
— Organizational freeze. All requirements live forever because no owner to cancel them.

Operational mechanics:

1. Every ticket / requirement / constraint must have a named owner. Not a team, not a department — Ivan Petrov.
2. Owner defends the requirement at any review. If they can't defend it — it's deleted.
3. Owner can delete their requirement without approvals. That's the verification that they have authority proportional to responsibility.
4. Owner changes — requirement changes. When a person leaves the team, their requirements are reviewed, not inherited.

In AI code context: AI eagerly implements whatever you ask, without asking «who requests this and why». Using AI without explicit human owner for every requirement amplifies the absence of accountability.

Ties: sect.42 (Musk's Algorithm — step 1), sect.21 (HOP), sect.56 (DRI — institutionalized version of the same principle at Apple), sect.65 (Hope is not a strategy).

Apple operating model, формализованный с эпохи Джобса. Описан James Stanier в «Effective Software Engineering Manager». DRI — это институциональная форма принципа sect.55 (personal accountability), применённая к продуктам, фичам, инцидентам и архитектурным решениям.

Свойства DRI:

1. Один и только один. Если на меетинге двое называют себя DRI одного артефакта — это уже не DRI. Решается до конца meeting'а.
2. Authority матчит responsibility. DRI имеет право принять решение без эскалации. Если ему нужно одобрение для каждого шага — это не DRI, это messenger.
3. Видим на уровне организации. DRI на ticket'е, на эпике, на инциденте — открытая информация. Каждый знает, кому идти с вопросом.
4. Несёт оба полюса. Кредит за успех — DRI. Ответственность за провал — DRI. Не разделяется.
5. Передаваем. DRI может явно передать роль другому, с подтверждением. Не «я уехал в отпуск, разбирайтесь сами».

Почему DRI > consensus:

— Скорость. Решение принимается без круга согласований. Меньше задержек, меньше политики.
— Качество decisions. Один человек с full context принимает лучшие решения, чем семь людей с разрозненным контекстом.
— Learning loop. Один человек видит результат своих решений → учится. В consensus modeli никто не учится.
— Audit trail. Через год можно спросить: «Почему это так сделано?» — есть человек, который ответит.

Где DRI ломается:

1. DRI без authority. Назначен, но каждое его решение требует sign-off менеджера. Это не DRI — это формальная роль.
2. DRI как «единственный, кто знает». Bus factor = 1. Должен быть документ передачи / shadow.
3. Слишком много ролей DRI на одном человеке. DRI на 15 областей = DRI ни на одной.
4. DRI без support. Один человек не может тянуть большой проект без команды.

Связки: sect.55 (Personal Accountability — теоретический фундамент), sect.21 (HOP — DRI это accountability на уровне сетки, не на уровне коллектива), sect.60 (ADR · Health · DRI — три инструмента менеджмента), sect.65 (Hope is not a strategy — DRI означает явный план, не надежду).

Apple operating model, formalized since the Jobs era. Described by James Stanier in «Effective Software Engineering Manager». DRI is the institutional form of the principle in sect.55 (personal accountability), applied to products, features, incidents, and architectural decisions.

DRI properties:

1. One and only one. If two people at a meeting claim DRI on the same artifact — it's not DRI yet. Resolved before meeting ends.
2. Authority matches responsibility. DRI can decide without escalation. If they need approval for each step — that's not DRI, that's a messenger.
3. Visible org-wide. DRI on a ticket, epic, incident — open information. Everyone knows who to ask.
4. Carries both poles. Credit for success — DRI. Responsibility for failure — DRI. Not split.
5. Transferable. DRI can explicitly hand off the role with acknowledgment. Not «I went on vacation, figure it out».

Why DRI > consensus:

— Speed. Decisions made without rounds of sign-offs. Fewer delays, less politics.
— Decision quality. One person with full context makes better decisions than seven with fragmented context.
— Learning loop. One person sees results of their decisions → learns. In consensus model nobody learns.
— Audit trail. A year later you can ask: «Why was it done this way?» — there's a person to answer.

Where DRI breaks:

1. DRI without authority. Appointed, but every decision needs manager sign-off. Not DRI — formal role only.
2. DRI as «the only one who knows». Bus factor = 1. Must have handoff doc / shadow.
3. Too many DRI roles on one person. DRI on 15 areas = DRI on none.
4. DRI without support. One person can't carry a big project without a team.

Ties: sect.55 (Personal Accountability — theoretical foundation), sect.21 (HOP), sect.60 (ADR · Health · DRI — three management tools), sect.65 (Hope is not a strategy).

Илон Маск, серия наблюдений из Tesla/SpaceX. Контр-интуитивный тезис, направленный против «менеджер как друг команды» модели. Менеджер выносит решения о повышениях, увольнениях, приоритетах — все эти решения создают недовольных. Универсальная популярность означает, что менеджер избегает hard calls.

Что делает менеджер-судья:

1. Performance reviews — честные. Не «у всех всё хорошо», а реальная картина с конкретными примерами. Это даёт людям шанс расти; «у всех всё хорошо» лишает их этого шанса.
2. Увольнения происходят вовремя. Когда становится ясно, что человек не подходит роли, действие — недели, не годы. Затягивание ведёт к более болезненному увольнению через год + ущерб команде, которая работает с ним всё это время.
3. Hard calls на приоритетах. Между проектами A и B, который любит команда, и проектом C, который нужен бизнесу, выбирается C — даже если это непопулярно.
4. Прямая критика в лицо. «Этот код плохой, потому что X». Не «может быть, стоит подумать, не лучше ли немного по-другому».
5. Не оборачивается на эмоциональные реакции. Если решение правильное, недовольство — данные, не аргумент.

Почему модель «менеджер как друг» вредна:

— Накапливается долг. Не решённые проблемы (плохой исполнитель, токсичный коллега, неправильный приоритет) растут, пока не взрываются в кризис.
— Лучшие уходят первыми. Top performers видят, что плохие исполнители не получают consequence, и уходят туда, где есть accountability.
— Невозможна objective оценка. Если менеджер другом всех, любая оценка читается как «личное».
— Менеджер сам становится bottleneck. Не делегирует hard decisions, потому что не хочет, чтобы коллеги принимали непопулярные решения и платили популярностью.

Граница между судьёй и тираном:

1. Судья — прозрачные критерии, видимые всем; решение можно apellate; ошибки судьи признаются публично.
2. Тиран — непредсказуемые решения; нельзя оспорить; ошибки скрываются.

Менеджер-судья непопулярен в моменте, но уважаем в долгом плане — потому что предсказуем и справедлив. Тиран ненавидим как в моменте, так и в долгом плане.

Связки: sect.61 (Уважение через результат), sect.53 (Servant Leadership — служение не означает sycophancy), sect.66 (Эго в продукте — отсутствие судьи приводит к торжеству эго), sect.7 (Price's Law — protect productive few = увольнять unproductive many).

Elon Musk, series of observations from Tesla/SpaceX. Counter-intuitive thesis, aimed against the «manager as team friend» model. A manager makes decisions about promotions, firings, priorities — all of which create dissatisfaction. Universal popularity means the manager avoids hard calls.

What a judge-manager does:

1. Performance reviews — honest. Not «everyone's doing fine», but real picture with specific examples. This gives people a chance to grow; «everyone's fine» deprives them of that chance.
2. Firings happen on time. When it becomes clear the person doesn't fit the role, action is weeks, not years. Dragging leads to more painful firing a year later + damage to the team working with them all that time.
3. Hard calls on priorities. Between projects A and B the team likes, and project C the business needs, C is chosen — even if unpopular.
4. Direct criticism to the face. «This code is bad because X». Not «maybe consider whether a slightly different approach might be better».
5. Doesn't bend to emotional reactions. If the decision is right, displeasure is data, not argument.

Why «manager as friend» model is harmful:

— Debt accumulates. Unresolved problems (poor performer, toxic colleague, wrong priority) grow until they explode into crisis.
— Best leave first. Top performers see poor performers face no consequences, and leave where accountability exists.
— Objective evaluation impossible. If the manager is friend to all, any evaluation reads as «personal».
— Manager becomes the bottleneck. Doesn't delegate hard decisions, because doesn't want colleagues making unpopular decisions and paying with popularity.

Line between judge and tyrant:

1. Judge — transparent criteria visible to all; decisions can be appealed; judge's mistakes are admitted publicly.
2. Tyrant — unpredictable decisions; can't be challenged; mistakes are hidden.

The judge-manager is unpopular in the moment but respected long-term — because predictable and fair. The tyrant is hated both in the moment and long-term.

Ties: sect.61 (Respect Through Results), sect.53 (Servant Leadership — service doesn't mean sycophancy), sect.66 (Ego in Product), sect.7 (Price's Law).

Илон Маск, многократно высказывается: «менеджер инженерной команды должен оставаться инженером». Похожая формулировка у Стива Возняка, Линуса Торвальдса, Bill Gates в раннюю эру Microsoft. Тезис: technical management — это applied engineering, не applied management.

Что значит «работать руками» для менеджера:

1. Читать production code на критическом пути. Не code reviews от своей команды, а реальный код, в который происходит большинство incidents.
2. Писать prototype когда обсуждается архитектурное решение. Не финальный код — proof of concept, который позволяет понять trade-offs.
3. Делать manual operational tasks хотя бы раз в квартал. Делать deploy руками, restore from backup, troubleshoot incident on-call.
4. Читать постмортемы как технический документ. Не «что произошло на бизнес-уровне», а «как это произошло технически».
5. Использовать собственный продукт. Менеджер CROSSx должен ежедневно открывать тот же UI, что и трейдеры.

Что НЕ есть «работа руками»:

— Подписывать code reviews без чтения diff'а.
— Open IDE раз в полгода и закрыть после двух минут.
— Просить инженеров «объяснить, что происходит» вместо самостоятельной проверки.
— Демонстративно сидеть в коде на показательных meetings.

Почему 20% — не больше:

Если менеджер пишет 50% времени, это значит, что он не делает manager-работу. Это две полные ставки на одном человеке, и обе будут страдать. 20% достаточно, чтобы:

— Понимать, что значит конкретный «5 дней работы» от инженера.
— Видеть code smells (sect.39) на architectural level.
— Замечать deviation между work-as-imagined и work-as-done (sect.21).
— Поддерживать кредит доверия команды: «он понимает, что делаем».

Почему 20% — не меньше:

Меньше 20% означает, что hands-on session случается раз в несколько месяцев. Это не калибровка — это spot-check, который скорее искажает, чем informs (потому что одна точка данных без context'а легко ведёт к неправильным выводам).

Связки: sect.21 (HOP — менеджер должен видеть work-as-done напрямую), sect.54 (Go to the Source), sect.57 (Manager как судья — судить можно только то, что понимаешь), sect.66 (Эго в продукте — менеджер, не пользующийся продуктом, делает решения по эго).

Elon Musk, repeatedly: «engineering team manager must remain an engineer». Similar formulation from Steve Wozniak, Linus Torvalds, early-era Bill Gates at Microsoft. Thesis: technical management is applied engineering, not applied management.

What «hands-on» means for a manager:

1. Read production code on the critical path. Not their team's code reviews, but actual code where most incidents happen.
2. Write a prototype when an architectural decision is being discussed. Not final code — a proof of concept that lets you understand trade-offs.
3. Do manual operational tasks at least once a quarter. Deploy by hand, restore from backup, troubleshoot incident on-call.
4. Read postmortems as technical documents. Not «what happened at business level», but «how it happened technically».
5. Use the product themselves. A CROSSx manager should open the same UI as traders daily.

What is NOT «hands-on»:

— Signing code reviews without reading the diff.
— Opening IDE once every six months and closing after two minutes.
— Asking engineers «explain what's happening» instead of checking themselves.
— Demonstratively sitting in code at showcase meetings.

Why 20% — not more:

If a manager writes 50% of the time, it means they don't do manager work. That's two full FTEs on one person, and both suffer. 20% is enough to:

— Understand what «5 days of work» from an engineer actually means.
— See code smells (sect.39) at architectural level.
— Notice deviation between work-as-imagined and work-as-done (sect.21).
— Maintain team trust credit: «they understand what we're doing».

Why 20% — not less:

Less than 20% means hands-on session happens once every few months. That's not calibration — it's spot-check, which distorts more than informs (because one data point without context easily leads to wrong conclusions).

Ties: sect.21 (HOP — manager must see work-as-done directly), sect.54 (Go to the Source), sect.57 (Manager as Judge), sect.66 (Ego in Product).

Илон Маск использует skip-level как обязательный инструмент. То же — Andy Grove в «High Output Management», Andrew Bosworth в Meta, Bill Gates в Microsoft. Skip-level это инфраструктура для go-to-source (sect.54), сделанная регулярной и легитимной.

Механика:

1. Регулярность. Skip-level не реактивный; идёт по расписанию (квартал/полугодие).
2. Без присутствия среднего менеджера. Иначе нет разницы с обычным cascading meeting'ом.
3. Открыто среднему менеджеру. Не conspiracy. Менеджер знает, что встреча была; sometimes даже знает темы. Не знает только: какие конкретно слова сказал инженер.
4. Фокус на что мешает, не на performance. Не «расскажи мне про работу твоего менеджера». А «что мешает тебе делать твою работу?». Если возникает feedback на менеджера — он принимается, но не provoked.
5. Skip-level не отменяет line manager. Это дополнительный канал, не replacement.

Что узнаёшь через skip-level и не узнаешь через line manager:

— Реальное состояние tooling. Менеджеры обычно сглаживают.
— Tribal knowledge. Информация, которую инженеры считают «всем очевидной», но что наверх не доходит.
— Workarounds и hacks. Что реально держит систему — это не то, что в архитектурных диаграммах.
— Невидимая работа. Поддержка legacy, обучение newcomers, on-call — это часто не появляется в reports.
— Структурные проблемы. Конфликты между командами, плохие интерфейсы, неработающие процессы.

Что мешает использовать skip-level:

— Средние менеджеры воспринимают как угрозу. «Босс хочет проверить мою команду». Antidote — make it routine, explicit, supportive.
— Инженеры не доверяют. «Если я скажу правду, моего менеджера накажут, а меня будут считать стукачом». Antidote — длительная история без репрессий за skip-level honesty.
— Топ-менеджер слишком занят. Skip-level meetings пропадают первыми из календаря в loaded weeks. Это маркер, что компания слишком завязана на top management bottleneck.

В контексте многоуровневой организации: в крупной компании skip-level можно делать на любую глубину. Принцип: чем больше уровней между источником и решением, тем чаще нужны skip channels. Three levels — раз в квартал. Five levels — раз в месяц для outliers (incidents, hiring quality, key projects).

Связки: sect.54 (Go to the Source — методологический фундамент), sect.21 (HOP — skip-level это канал работы с work-as-done), sect.53 (Servant Leadership — служение требует знания о реальной нужде).

Elon Musk uses skip-level as a mandatory tool. Same — Andy Grove in «High Output Management», Andrew Bosworth at Meta, Bill Gates at Microsoft. Skip-level is the infrastructure for go-to-source (sect.54), made regular and legitimate.

Mechanics:

1. Regularity. Skip-level isn't reactive; it's scheduled (quarter/semester).
2. Without the middle manager present. Otherwise no difference from a regular cascading meeting.
3. Open to the middle manager. No conspiracy. The manager knows the meeting happened; sometimes even knows the topics. Doesn't know: which specific words the engineer said.
4. Focus on what blocks you, not performance. Not «tell me about your manager's work». But «what's blocking you from doing your work?». If feedback on the manager arises — accepted, not provoked.
5. Skip-level doesn't replace line manager. Additional channel, not replacement.

What you learn via skip-level and don't via line manager:

— Real state of tooling. Managers usually smooth it out.
— Tribal knowledge. Info engineers consider «obvious to all», which never reaches top.
— Workarounds and hacks. What actually holds the system together — not what's in architecture diagrams.
— Invisible work. Legacy support, newcomer training, on-call — often missing from reports.
— Structural problems. Inter-team conflicts, bad interfaces, broken processes.

What blocks skip-level usage:

— Middle managers feel threatened. «Boss wants to inspect my team». Antidote — make it routine, explicit, supportive.
— Engineers don't trust. «If I tell the truth, my manager gets punished and I'm a snitch». Antidote — long history of no retaliation for skip-level honesty.
— Top manager too busy. Skip-levels drop first from calendar in loaded weeks. That's a marker that the company is too dependent on the top-management bottleneck.

In a multi-level org: in a big company, skip-level can go to any depth. Principle: more levels between source and decision → more skip channels needed. Three levels — quarterly. Five levels — monthly for outliers (incidents, hiring quality, key projects).

Ties: sect.54 (Go to the Source — methodological foundation), sect.21 (HOP), sect.53 (Servant Leadership).

James Stanier, «Effective Software Engineering Manager», формализует «three tools» — минимальный набор артефактов для архитектурного управления. Каждый из них существует и в isolation, но сила в их связи: ADR говорит о прошлом, Health о настоящем, DRI о будущем (кто будет действовать).

1. ADR — Architectural Decision Record.

Документ с фиксированной структурой: context · решение · альтернативы · последствия · кто DRI · когда пересматривается. Каждое архитектурное решение (выбор стека, разделение сервисов, выбор протокола, retention policy) фиксируется как ADR.

Почему критично: через 2 года никто не помнит, почему выбрали Kafka вместо RabbitMQ, и команда либо переделывает (дорого), либо принимает as given (вредно). ADR делает audit trail возможным.

2. Health Checks.

Регулярная (раз в квартал) оценка состояния системы по фиксированным dimensions: technology, codebase, deployment, testing, on-call burden, team morale, documentation. Каждая dimension — green / amber / red, с конкретным обоснованием.

Почему критично: без health checks deterioration происходит постепенно и незаметно, пока не пробивает порог. С health checks видна траектория: «testing был green год назад, сейчас amber → инвестировать или принять risk».

3. DRI — см. sect.56.

Каждый ADR и каждая dimension health check имеют named owner. Не «команда X», a Иван Петров. Это превращает абстрактную картину в actionable.

Связь трёх инструментов:

1. Health Check показывает «testing amber».
2. Это триггерит решение: либо принять risk (ADR: «accepting current testing posture, revisit Q3»), либо инвестировать.
3. У решения есть DRI: «Иван Петров отвечает за достижение green к Q3».
4. В Q3 снова Health Check; если по-прежнему amber — Иван объясняет, почему. Эскалация или re-decision.

Эта связка делает архитектурное управление scientific, а не intuitive.

Антипаттерны:

— ADR существуют, но никто не читает. Бюрократия без эффекта. Antidote — ADR обязателен только для решений, которые сложно/дорого откатить.
— Health checks как theater. Все green каждый квартал. Это означает, что критерии нечестные. Должен быть хотя бы один amber на любой нетривиальной команде.
— DRI без authority. Назначен, но без власти решать. См. sect.56.
— Слишком много ADR. Каждое решение становится формальностью; читать невозможно. ADR — для важных, не для всех.

Связки: sect.56 (DRI), sect.55 (Personal Accountability), sect.21 (HOP — health checks это observable state системы), sect.69 (Pain Index — health check для бизнес-системы).

James Stanier, «Effective Software Engineering Manager», formalizes «three tools» — minimal artifact set for architectural management. Each exists in isolation, but the power is in their connection: ADR speaks of the past, Health of the present, DRI of the future (who will act).

1. ADR — Architectural Decision Record.

Document with fixed structure: context · decision · alternatives · consequences · DRI · when revisited. Each architectural decision (stack choice, service split, protocol choice, retention policy) is recorded as an ADR.

Why critical: in 2 years nobody remembers why Kafka over RabbitMQ, and the team either redoes (expensive) or accepts as-given (harmful). ADR makes the audit trail possible.

2. Health Checks.

Regular (quarterly) assessment of system state across fixed dimensions: technology, codebase, deployment, testing, on-call burden, team morale, documentation. Each dimension — green / amber / red, with specific justification.

Why critical: without health checks, deterioration happens gradually and invisibly until threshold breach. With health checks, the trajectory is visible: «testing was green a year ago, now amber → invest or accept risk».

3. DRI — see sect.56.

Each ADR and each health check dimension has a named owner. Not «team X», but Ivan Petrov. Turns abstract picture into actionable.

How the three connect:

1. Health Check shows «testing amber».
2. This triggers a decision: either accept risk (ADR: «accepting current testing posture, revisit Q3»), or invest.
3. The decision has a DRI: «Ivan Petrov responsible for green by Q3».
4. Q3 health check again; if still amber — Ivan explains why. Escalation or re-decision.

This loop makes architectural management scientific rather than intuitive.

Anti-patterns:

— ADRs exist but nobody reads them. Bureaucracy without effect. Antidote — ADR required only for decisions hard/expensive to undo.
— Health checks as theater. All green every quarter. Means criteria are dishonest. Should be at least one amber on any non-trivial team.
— DRI without authority. Appointed, but no power to decide. See sect.56.
— Too many ADRs. Every decision becomes a formality; reading impossible. ADR is for important ones, not all.

Ties: sect.56 (DRI), sect.55 (Personal Accountability), sect.21 (HOP), sect.69 (Pain Index).

Илон Маск, провокационная формулировка. Точный смысл: empathy полезна как информационный канал (понимание контекста других), но деструктивна как критерий принятия решений. Если решение оптимизирует «не обидеть», а не «правильно» — это плохое решение, даже если все улыбаются.

Источники уважения, ранжированные:

1. Результаты команды. Менеджер, под чьим руководством команда отгружает работающие системы, получает уважение автоматически. Это самый сильный источник.
2. Качество решений. Решения, которые задним числом оказываются правильными. Через 2 года команда вспоминает: «он был прав тогда, когда мы все думали иначе».
3. Honest feedback. Менеджер, который говорит правду, даже неудобную, уважаем — потому что его слова имеют ценность.
4. Защита команды. Менеджер, абсорбирующий внешнее давление, не делегирующий его вниз. Команда видит и помнит.
5. Technical credibility. Менеджер, способный обсуждать технику на equal level (sect.58 — 20% hands-on).

Что НЕ работает как источник уважения:

— Title. На bullshit job titles team смотрит снисходительно через 2 недели.
— Любезность. Уважение и симпатия — разные things; путать опасно.
— Открытость к feedback (без действия). «Я всегда готов выслушать» без следующих решений = театр.
— Performative humility. «Я учусь у команды каждый день» — если за этим нет реальных decisions, в которых менеджер поменял мнение.

Желание нравиться — главная ловушка:

Менеджер, для которого важно нравиться, систематически делает следующие ошибки:

1. Откладывает увольнения недостаточных performers.
2. Не даёт прямой негативный feedback на performance review.
3. Соглашается с громким мнением вместо тихого правильного.
4. Покрывает чужие ошибки вместо требования accountability.
5. Принимает популярные приоритеты вместо нужных бизнесу.

Каждое такое решение поодиночке кажется small. Сумма — failed team в течение года.

Граница: уважение vs запугивание.

Уважение через результат не означает грубость. Менеджер может быть direct и одновременно respectful. Жёсткий feedback по технике + личное уважение к человеку — стандартная формула. Disrespect → не уважение, а страх; страх → не уважение, а уход top performers.

Связки: sect.57 (Manager как судья), sect.66 (Эго в продукте — желание нравиться часто проявляется как ego-driven решения), sect.7 (Price's Law — protect productive few, что часто непопулярно).

Elon Musk, provocative formulation. Precise meaning: empathy is useful as an information channel (understanding others' context) but destructive as a decision criterion. If a decision optimizes for «not offending» instead of «right» — it's a bad decision, even if everyone smiles.

Sources of respect, ranked:

1. Team results. A manager under whose leadership the team ships working systems earns respect automatically. Strongest source.
2. Decision quality. Decisions that turn out right in hindsight. Two years later the team remembers: «he was right when we all thought otherwise».
3. Honest feedback. A manager who tells the truth, even uncomfortable, is respected — because their words carry value.
4. Team protection. A manager absorbing external pressure, not delegating it down. The team sees and remembers.
5. Technical credibility. A manager able to discuss technique at equal level (sect.58 — 20% hands-on).

What doesn't work as a respect source:

— Title. The team looks past bullshit job titles within 2 weeks.
— Niceness. Respect and sympathy are different things; conflating is dangerous.
— Openness to feedback (without action). «I'm always ready to listen» without subsequent decisions = theater.
— Performative humility. «I learn from the team every day» — if no real decisions follow where the manager changed their mind.

Wanting to be liked is the main trap:

A manager for whom being liked matters systematically makes these mistakes:

1. Defers firings of inadequate performers.
2. Doesn't give direct negative feedback at performance reviews.
3. Agrees with the loud opinion instead of the quiet correct one.
4. Covers others' mistakes instead of demanding accountability.
5. Accepts popular priorities instead of business-needed ones.

Each decision alone seems small. The sum — failed team within a year.

Boundary: respect vs intimidation.

Respect through results doesn't mean rudeness. A manager can be direct and respectful simultaneously. Hard feedback on technique + personal respect for the human — standard formula. Disrespect → not respect, but fear; fear → not respect, but top performers leaving.

Ties: sect.57 (Manager as Judge), sect.66 (Ego in Product), sect.7 (Price's Law).

Илон Маск, многократно повторяется в hiring practice Tesla/SpaceX. То же — Howard Schultz в Starbucks, Herb Kelleher в Southwest. Тезис: hiring filter должен оптимизировать долгосрочную траекторию, а не сегодняшнюю задачу.

Что значит «attitude» в инженерной среде:

1. Любопытство. «Как это работает?» — реакция по умолчанию, а не «как это использовать».
2. Ownership. «Я починю», а не «это чужая зона».
3. Bias toward action. Принимает несовершенные решения и итерирует; не парализован analysis paralysis.
4. Прямая коммуникация. Говорит, что думает; принимает прямой feedback в ответ.
5. Готовность быть неправым. Меняет позицию при появлении новых данных; не цепляется за прошлые мнения.
6. Высокий standard. Что-то «работает» — не критерий; критерий — «работает хорошо».

Почему skill менее важен:

— Технология меняется каждые 2 года. Сегодняшний senior на React через 5 лет будет учить новый framework.
— Senior уровень в любом языке достижим за 2-3 года при правильном attitude.
— Skills легче assessable на interview, чем attitude — поэтому over-weighted в скрининге.
— Skill gap виден сразу и решается обучением; attitude gap виден через год и не решается.

Когда правило не применяется:

1. Critical specialization. Если ищешь embedded engineer на rocket telemetry — attitude важен, но skill — обязательный фильтр, не fungible.
2. Tight deadlines. Когда нужна продуктивность завтра, нет времени на обучение. Но это краткосрочное решение, имеющее долгосрочную цену.
3. Small team. В команде из 5 человек один inappropriate hire — это 20% состава. Attitude важнее всего, но и skill не может быть нулевым.

Как оценить attitude в interview:

— Поведенческие вопросы про прошлые failures. Что человек сделал, когда сильно ошибся? Признал → исправил → научился — или скрыл и переложил?
— Реакция на pushback. Дай противоречивую гипотезу про его прошлое решение. Защищает позицию? Слушает? Меняет мнение при argument'е?
— Trial-and-error в задаче. Coding task, в которой первое решение должно не работать. Что делает дальше — паника, irrational sticking, или systematic debugging?
— Reference check на attitude. Спрашивать у прошлого менеджера не «насколько он хорош технически», а «как он реагирует, когда не получается».

Связки: sect.63 (Свежая кровь), sect.64 (Дискомфорт полезен), sect.7 (Price's Law — top performers это не всегда top skills, чаще top attitude).

Elon Musk, repeated often in Tesla/SpaceX hiring practice. Same — Howard Schultz at Starbucks, Herb Kelleher at Southwest. Thesis: the hiring filter should optimize the long-term trajectory, not today's task.

What «attitude» means in an engineering setting:

1. Curiosity. «How does this work?» is the default reaction, not «how do I use this».
2. Ownership. «I'll fix it» rather than «that's someone else's zone».
3. Bias toward action. Makes imperfect decisions and iterates; not paralyzed by analysis paralysis.
4. Direct communication. Says what they think; takes direct feedback in return.
5. Willingness to be wrong. Changes position when new data appears; doesn't cling to past opinions.
6. High standard. «It works» isn't a criterion; the criterion is «it works well».

Why skill matters less:

— Technology changes every 2 years. Today's React senior will be learning a new framework in 5 years.
— Senior level in any language is reachable in 2-3 years with the right attitude.
— Skills are easier to assess in interviews than attitude — therefore over-weighted in screening.
— Skill gap is visible immediately and solvable through training; attitude gap is visible in a year and isn't solvable.

When the rule does not apply:

1. Critical specialization. Hiring an embedded engineer for rocket telemetry — attitude matters, but skill is a hard filter, not fungible.
2. Tight deadlines. When productivity is needed tomorrow, no time for training. But that's a short-term decision with long-term cost.
3. Small team. In a 5-person team, one inappropriate hire is 20% of headcount. Attitude matters most, but skill can't be zero.

How to assess attitude in interviews:

— Behavioral questions on past failures. What did they do when they made a major mistake? Owned → fixed → learned — or hid and shifted?
— Reaction to pushback. Offer a contrarian hypothesis about their past decision. Defends? Listens? Updates with argument?
— Trial-and-error in a task. A coding task where the first solution must fail. What do they do next — panic, irrational sticking, or systematic debugging?
— Reference check on attitude. Ask their previous manager not «how good technically» but «how do they react when things go wrong».

Ties: sect.63 (Fresh Blood), sect.64 (Discomfort is Useful), sect.7 (Price's Law).

Илон Маск, наблюдение из Tesla и SpaceX. Эта идея противоположна привычной mantra «retention выше всего». Тезис: 100% retention — плохой знак. Это значит, что либо плохие исполнители не уходят (sect.57), либо команда стабилизировалась в local optimum и не challenged.

Что даёт свежая кровь:

1. Внешний baseline. Новый человек смотрит на ваши практики глазами outsider'а. «Почему вы это делаете так? У нас в X было по-другому». Это — самый дешёвый источник challenge'а к assumptions.
2. Разрушение группового мышления. Команда из 5 лет общей работы говорит на одном языке и не замечает blind spots. Новый человек блокирует groupthink просто своим присутствием.
3. Новые навыки. Не обязательно better, но different. Это расширяет solution space команды.
4. Контроль над комфортом. Когда команда привыкает, что «всё хорошо», новый человек, спрашивающий неудобные вопросы — это маркер качества культуры.

Какая доля «свежей крови» оптимальна:

В стабильной зрелой компании здоровый turnover — 10-15% в год (Bain & Co исследования). Меньше 5% — стагнация. Больше 25% — chaos. В быстрорастущих компаниях верхняя граница выше: 30-40% при росте 50% per year — нормально.

Эти числа применяются к команде в целом, не к каждому role'у. На некоторых критических ролях ты хочешь low turnover (например, principal architect). На других — high turnover здоров (junior pipeline, специализированные роли).

Антипаттерны «свежей крови»:

1. Forced churn. Увольнения по квоте «20% bottom». Это другая патология — Goodhart-driven hr policy.
2. Hiring через staffing agencies без attitude filter. Свежее тело ≠ свежая кровь. Если new hire — это просто warm body, проблема не решена.
3. Onboarding broken. Свежий человек, не получивший контекст за 3 месяца, не challenge'ит assumptions — он tries to survive.
4. Свежие люди подавляются старыми. «Здесь так не делают». Если культура подавляет new perspectives — свежая кровь не даёт effect.

Связь с retention:

Retention — не цель. Цель — keep right people, let go wrong ones. Менеджер, оптимизирующий «никто не уходит», часто оптимизирует под комфорт. Это плохой proxy для культуры. Правильный proxy — voluntary attrition среди top performers (sect.7). Они уходят первыми из плохой культуры; они остаются в хорошей.

Связки: sect.62 (Hire by Attitude), sect.7 (Price's Law), sect.64 (Дискомфорт полезен), Meadows traps (drift к посредственности).

Elon Musk, observation from Tesla and SpaceX. The idea opposes the usual «retention above all» mantra. Thesis: 100% retention is a bad sign. It means either poor performers don't leave (sect.57), or the team has stabilized in a local optimum and isn't challenged.

What fresh blood provides:

1. External baseline. A new person sees your practices through outsider eyes. «Why do you do it this way? At X it was different». The cheapest source of challenge to assumptions.
2. Breaking groupthink. A team of 5 years' shared work speaks one language and misses blind spots. A new person blocks groupthink by presence alone.
3. New skills. Not necessarily better, but different. Expands the team's solution space.
4. Comfort control. When the team gets used to «all is well», a new person asking uncomfortable questions is a marker of culture quality.

What fraction of «fresh blood» is optimal:

In a stable mature company, healthy turnover is 10-15% per year (Bain & Co research). Below 5% — stagnation. Above 25% — chaos. In fast-growing companies, the upper bound is higher: 30-40% at 50% per year growth — normal.

These numbers apply to the team overall, not every role. On some critical roles, you want low turnover (e.g., principal architect). On others, high turnover is healthy (junior pipeline, specialized roles).

«Fresh blood» anti-patterns:

1. Forced churn. Firings by «bottom 20%» quota. A different pathology — Goodhart-driven HR policy.
2. Hiring via staffing agencies without attitude filter. Fresh body ≠ fresh blood. If new hire is just a warm body, the problem isn't solved.
3. Broken onboarding. Fresh person not given context in 3 months doesn't challenge assumptions — they try to survive.
4. Fresh people suppressed by veterans. «We don't do it like that here». If culture suppresses new perspectives — fresh blood has no effect.

Tie to retention:

Retention isn't the goal. The goal is keep right people, let go wrong ones. A manager optimizing «nobody leaves» often optimizes for comfort. Bad proxy for culture. Right proxy — voluntary attrition among top performers (sect.7). They leave first from bad culture; they stay in good.

Ties: sect.62 (Hire by Attitude), sect.7 (Price's Law), sect.64 (Discomfort is Useful), Meadows traps (drift to mediocrity).

Илон Маск, формализуется в его «hardcore» culture у Tesla, SpaceX, Twitter (после acquisition). Также — Patrick Collison в Stripe, Brian Chesky в Airbnb. Это контр-интуитивная позиция в эпоху, когда стандарт — comfort-first.

Тезис, разделённый на части:

1. Comfort — это не цель, это побочный эффект. Когда команда производит outstanding results, она получает уважение, autonomy, ресурсы — это форма комфорта. Когда команда оптимизирует comfort напрямую, она теряет результаты, что в долгом плане убивает комфорт.
2. Discomfort — driver роста. Стоматолог растёт, делая сложные операции, не лёгкие. Инженер растёт через проекты на пределе возможностей, не через предсказуемые tasks.
3. Контроль — критический modifier. Discomfort должен быть voluntary, target'ed, и periodically. Постоянное burnout — не discomfort, а pathology.

Что такое «полезный дискомфорт» в инженерной команде:

— Hard deadlines на real projects. Не arbitrary, а связанные с реальной business reality. «Эта система должна работать к Q3, потому что иначе мы теряем major client».
— Direct critical feedback. Не sandwich method, а straight talk. Болезненно в моменте, growth-driving в долгом плане.
— Высокий standard на code quality, design, communication. Не «работает» — «works well».
— Public accountability. Решения и их authors видимы. Это создаёт пространство для роста и для ответственности.
— Periodic «stretch» tasks. Каждый инженер раз в полгода берёт задачу за пределами своей зоны.

Что НЕ есть полезный дискомфорт:

1. Хронический overwork. 60-часовая неделя как постоянный режим — это не discomfort, это extraction value до того, как человек сгорит.
2. Произвольная грубость. «Hardcore» культуры часто превращаются в карикатуру, где dehumanization подаётся как «excellence».
3. Стрессы без agency. Если человек не имеет контроля над тем, как решает задачу, дискомфорт — это просто abuse.
4. Discomfort на ровном месте. Без связи с реальной business need — это performance theater.

Hardcore как hiring filter:

Это часть второго правила (sect.62 — hire by attitude). Сильный attitude комфортен с дискомфортом; weak attitude ищет минимальный discomfort. Если команда подаётся как «high standards, hard work, direct culture» — это автоматически фильтрует weak attitudes до interview'а.

Риск: filter может работать против diversity, против людей с care responsibilities, против тех, кто оптимизирует career иначе. Это trade-off, который надо принимать осознанно.

Связки: sect.62 (Hire by Attitude), sect.63 (Свежая кровь), sect.57 (Manager как судья), sect.61 (Уважение через результат — результат требует дискомфорта).

Elon Musk, formalized in his «hardcore» culture at Tesla, SpaceX, Twitter (post-acquisition). Also — Patrick Collison at Stripe, Brian Chesky at Airbnb. A counter-intuitive position in an era where comfort-first is the default.

The thesis, broken down:

1. Comfort isn't the goal, it's a side effect. When a team produces outstanding results, it earns respect, autonomy, resources — a form of comfort. When a team optimizes comfort directly, it loses results, which long-term kills comfort.
2. Discomfort is a driver of growth. A dentist grows doing hard surgeries, not easy ones. An engineer grows through projects at the edge of capability, not predictable tasks.
3. Control is the critical modifier. Discomfort must be voluntary, targeted, and periodic. Constant burnout isn't discomfort, it's pathology.

What «useful discomfort» means in an engineering team:

— Hard deadlines on real projects. Not arbitrary, but connected to actual business reality. «This system must work by Q3 because otherwise we lose a major client».
— Direct critical feedback. Not the sandwich method, but straight talk. Painful in the moment, growth-driving long-term.
— High standards on code quality, design, communication. Not «works» — «works well».
— Public accountability. Decisions and their authors visible. Creates space for growth and responsibility.
— Periodic «stretch» tasks. Each engineer takes a task beyond their zone once every six months.

What is NOT useful discomfort:

1. Chronic overwork. 60-hour week as constant regime — not discomfort, extraction value before the person burns out.
2. Arbitrary rudeness. «Hardcore» cultures often turn into caricature where dehumanization is sold as «excellence».
3. Stress without agency. If a person has no control over how they solve a task, discomfort is just abuse.
4. Discomfort for its own sake. Without ties to real business need — performance theater.

Hardcore as hiring filter:

Part of rule two (sect.62 — hire by attitude). Strong attitude is comfortable with discomfort; weak attitude seeks minimal discomfort. If the team is pitched as «high standards, hard work, direct culture» — it automatically filters weak attitudes before interview.

Risk: the filter may work against diversity, against people with care responsibilities, against those optimizing career differently. A trade-off to accept consciously.

Ties: sect.62 (Hire by Attitude), sect.63 (Fresh Blood), sect.57 (Manager as Judge), sect.61 (Respect Through Results).

Google SRE book, основополагающий принцип. Цитата ставится в начало главы про reliability: любое решение, validation которого опирается на «надеемся, всё будет хорошо», — это не решение. Это perfect example open-loop системы: ты не узнаешь о проблеме до того, как она проявится во вред.

Operational test для каждой инициативы:

1. Какой feedback loop скажет, что это работает? Если ответ — «увидим через год по результатам бизнеса» — это hope, не strategy.
2. Какой signal указал бы, что это не работает? Если не можешь чётко описать failure mode, ты не понимаешь, что делаешь.
3. Сколько по времени до того, как loop замкнётся? Loop в неделях — хорошо. Loop в годах — это hope с дополнительной шагов.
4. Кто наблюдает за loop? DRI на signal'ы (sect.56). Loop без DRI = no loop.

Канонические случаи hope-as-strategy:

— «Эта система масштабируется до 10x». Никто не пробовал. Никто не знает, что произойдёт. Это hope.
— «Команда сама разберётся». Без явного DRI, без checkpoints, без сигнала об отклонении — это hope.
— «Пользователи примут изменение». Без A/B test, без feedback channels — hope.
— «Документация устарела, но все знают, как работает». Hope. До первого ухода.
— «Бекапы работают». Без regular restore drills — hope. Конструктивный backup — это тот, который восстанавливали ВЧЕРА.

Strategy vs hope — операционная разница:

Strategy = action + observable signal + responder + recovery path. Hope = action + assumption + no signal + no responder.

Если хоть один элемент в quartet'е strategy отсутствует, ты в hope-режиме. Это не плохо само по себе для low-stakes ситуаций; катастрофически для high-stakes.

Связь с SLA/SLO:

SLO существует именно для того, чтобы перевести «hope it's reliable» в «strategy with signals». «Availability 99.9%» — это targeted signal. Когда падает ниже — error budget горит, что триггерит конкретные действия. Без SLO «reliability» — это hope, как бы много инвестиций в неё не было.

В контексте AI-систем: «AI будет вести себя правильно в проде» без monitoring, без evaluation на live traffic, без kill switch — это hope в exponentially более опасной форме. AI-deployment без observability — самая дорогая форма этого антипаттерна сегодня.

Связки: sect.20 (Chaos Engineering — намеренное тестирование, чтобы выйти из hope-режима), sect.22 (Resilience Engineering), sect.55 (Personal Accountability — без owner-loop нет strategy), sect.60 (Health Checks).

Google SRE book, foundational principle. The quote opens the reliability chapter: any decision whose validation rests on «we hope it'll be fine» isn't a decision. It's a perfect open-loop system: you don't learn about the problem until it manifests as harm.

Operational test for every initiative:

1. What feedback loop tells you this works? If the answer is «we'll see in a year by business results» — that's hope, not strategy.
2. What signal would indicate it's not working? If you can't clearly describe a failure mode, you don't understand what you're doing.
3. How long until the loop closes? Loop in weeks — good. Loop in years — hope with extra steps.
4. Who watches the loop? DRI on the signals (sect.56). Loop without DRI = no loop.

Canonical hope-as-strategy cases:

— «This system scales 10x». Nobody tried. Nobody knows what'll happen. Hope.
— «The team will figure it out». Without explicit DRI, without checkpoints, without deviation signal — hope.
— «Users will accept the change». Without A/B test, without feedback channels — hope.
— «Docs are stale but everyone knows how it works». Hope. Until the first departure.
— «Backups work». Without regular restore drills — hope. A constructive backup is one that was restored YESTERDAY.

Strategy vs hope — operational difference:

Strategy = action + observable signal + responder + recovery path. Hope = action + assumption + no signal + no responder.

If even one element of the strategy quartet is missing, you're in hope mode. Not bad in itself for low-stakes situations; catastrophic for high-stakes.

Tie to SLA/SLO:

SLO exists precisely to convert «hope it's reliable» into «strategy with signals». «99.9% availability» is a targeted signal. When it dips below — error budget burns, triggering concrete actions. Without SLO, «reliability» is hope, no matter the investment.

In AI systems context: «AI will behave correctly in prod» without monitoring, without live-traffic evaluation, without kill switch — hope in an exponentially more dangerous form. AI deployment without observability is the costliest form of this anti-pattern today.

Ties: sect.20 (Chaos Engineering — deliberate testing to escape hope-mode), sect.22 (Resilience Engineering), sect.55 (Personal Accountability), sect.60 (Health Checks).

Антипаттерн, ярко проявившийся в эпоху acquisition Twitter Маском (2022-2024). Аналогичные эпизоды — Quibi (Katzenberg), Google+ (Vic Gundotra), Apple Maps launch (2012, Forstall). Общая структура: founder/leader с success record решает, что его интуиция важнее данных и user feedback. Результат: продукт оптимизируется под personal preferences одного человека, а не под пользователей.

Что отличает эго-driven от vision-driven:

1. Vision-driven: «у пользователей есть проблема X, она будет решена через Y». Тестируется. Если данные противоречат — vision корректируется.
2. Ego-driven: «я хочу, чтобы было Y». Данные, противоречащие этому, объявляются «не понимающими vision». Любая критика — атака на founder'а.

Симптомы:

— Решения по preferences founder'а. «Я не пользуюсь этой кнопкой, поэтому удалим её для всех».
— Disagreement = disloyalty. Кто говорит «данные показывают другое» — увольняется или маргинализируется.
— A/B tests отменяются. «Слишком долго; мы знаем, что правильно».
— User research игнорируется. «Пользователи не знают, чего хотят».
— Random изменения, обоснованные интуицией. Без гипотезы, без metric, без feedback loop.
— Феномен «yes-men». Управленческий слой обнаруживает, что соглашаться карьерно безопасно; honest feedback редеет.

Парадокс success record:

Эго-decisions особенно опасны от тех, кто раньше делал правильные intuition-based calls. Эта success record даёт им (и команде) confidence в текущей интуиции, при том что:

1. Прошлые решения принимались в другом контексте.
2. Прошлые удачи могли быть частично везением (sect.72 — WYSIATI).
3. Сейчас другой product, другой rynok, другие пользователи.

«Я уже делал это раньше» — самое опасное обоснование в product decisions.

Защита от ego-creep:

1. Mandatory data sign-off на крупных решениях. Не «согласовано с founder'ом», а «прошло metric review».
2. Decision logs. Каждое крупное решение — с гипотезой, ожидаемой метрикой, sign-off date. Это создаёт audit trail и forces explicit reasoning.
3. Devil's advocate as role. Кто-то с явным полномочием возражать — без карьерного риска.
4. External signal как circuit breaker. Когда retention падает на 20%, automatic re-review последних 3 product decisions.
5. Founder uses the product. Связано с sect.58 — но в обратную сторону: founder должен иметь experience типичного пользователя, не только power-user'а с custom setup.

Связки: sect.47 (Problem-First — ego это противоположность customer-first), sect.54 (Go to the Source — founder, не идущий к источнику, действует по эго), sect.57 (Manager как судья — но судит по фактам, не по personal preference), sect.72 (WYSIATI — cognitive bias, лежащий в основе ego-decisions).

An anti-pattern starkly visible in the Twitter acquisition era under Musk (2022-2024). Similar episodes — Quibi (Katzenberg), Google+ (Vic Gundotra), Apple Maps launch (2012, Forstall). Common structure: a founder/leader with a success record decides their intuition outweighs data and user feedback. Result: the product optimizes for one person's personal preferences, not for users.

What separates ego-driven from vision-driven:

1. Vision-driven: «users have problem X, it'll be solved via Y». Tested. If data disagrees — vision is adjusted.
2. Ego-driven: «I want Y». Data contradicting it is declared «not understanding the vision». Any criticism is an attack on the founder.

Symptoms:

— Decisions by founder preferences. «I don't use this button, so we'll remove it for everyone».
— Disagreement = disloyalty. Whoever says «data shows otherwise» is fired or marginalized.
— A/B tests cancelled. «Too slow; we know what's right».
— User research ignored. «Users don't know what they want».
— Random changes justified by intuition. No hypothesis, no metric, no feedback loop.
— Yes-men phenomenon. The management layer discovers agreement is career-safe; honest feedback thins.

The success-record paradox:

Ego decisions are especially dangerous from those who previously made correct intuition-based calls. That record gives them (and the team) confidence in current intuition, even though:

1. Past decisions were made in a different context.
2. Past wins might have been partly luck (sect.72 — WYSIATI).
3. Now there's a different product, market, users.

«I've done this before» is the most dangerous justification in product decisions.

Defense against ego-creep:

1. Mandatory data sign-off on major decisions. Not «approved by founder», but «passed metric review».
2. Decision logs. Every major decision — with hypothesis, expected metric, sign-off date. Creates audit trail and forces explicit reasoning.
3. Devil's advocate as role. Someone explicitly empowered to object — without career risk.
4. External signal as circuit breaker. When retention drops 20%, automatic re-review of last 3 product decisions.
5. Founder uses the product. Related to sect.58 — but in reverse: founder must have typical-user experience, not just power-user with custom setup.

Ties: sect.47 (Problem-First — ego is the opposite of customer-first), sect.54 (Go to the Source), sect.57 (Manager as Judge — but judging by facts, not personal preference), sect.72 (WYSIATI).

Eric Raymond, «The Cathedral and the Bazaar». Категория «killer» — это product, для которого вопрос «что использовать?» имеет тривиальный ответ. Это редкое состояние; для большинства tools всегда есть несколько разумных конкурентов.

Канонические killer categories:

— Git для distributed version control. После Linux kernel поднял его в 2005, всё остальное (Mercurial, Bazaar, Perforce) проиграло.
— SQLite для embedded database. Никто не спорит. Простота × ubiquity × free.
— nginx в момент 2010-2018 для reverse proxy. Apache не выдержал.
— Slack в 2014-2018 для team chat. Перестал быть killer когда Microsoft Teams и Discord нашли свои ниши.
— Stripe для payment integration. До сих пор default.

Каждый из них — match между конкретной болью и конкретным дизайном инструмента. Не «продукт для всех нужд», а «инструмент, который делает одну вещь так хорошо, что искать альтернативы кажется неразумным».

Структура killer-category продукта:

1. Сфокусирована проблема. Не «коммуникация», а «асинхронные обмены сообщениями для команды».
2. Низкий entry barrier. Можно начать пользоваться за минуты. Нет 50-страничного onboarding.
3. Высокий top-end. Power user'ы тоже находят, что нужно. Не toy.
4. Композитный интерфейс (sect.46 — Lesson 14). API/CLI/web — выбирай. Не lock-in в один способ.
5. Network effects или standards effects. Чем больше используют, тем дороже не использовать.

Что отличает killer category от market leader:

Market leader — большая доля рынка. Killer category — состояние, в котором альтернативы не рассматриваются. Microsoft Word — market leader, не killer. Google Search — killer. Razlika в том, что для Word есть rational reasons выбрать LibreOffice; для Google — нет equivalent reason выбрать Bing для большинства задач.

Стратегия для startup:

1. Найди узкую нишу. Не «лучший X», а «единственный разумный выбор для very specific use case».
2. Сделай дизайн perfect для этой ниши. Не trying to be general purpose.
3. Только потом expand. После того как доминируешь в нише — adjacent expansion.
4. Защити выбранную нишу через standards / network / depth. Switching cost должен расти со временем.

Связки: sect.46 (Lesson 14 — atomic primitive + композиция = killer foundation), sect.32 (Whole Product — killer category формируется когда whole product собран), sect.31 (Crossing the Chasm — killer status начинается с beachhead в нише).

Eric Raymond, «The Cathedral and the Bazaar». A «killer» category is one where the question «what to use?» has a trivial answer. A rare state; for most tools there are always several reasonable competitors.

Canonical killer categories:

— Git for distributed version control. After Linus elevated it in 2005, everything else (Mercurial, Bazaar, Perforce) lost.
— SQLite for embedded databases. Nobody argues. Simplicity × ubiquity × free.
— nginx from 2010-2018 for reverse proxy. Apache couldn't hold.
— Slack 2014-2018 for team chat. Stopped being killer when MS Teams and Discord found their niches.
— Stripe for payment integration. Still default.

Each is a match between a specific pain and a specific tool design. Not «product for all needs», but «a tool that does one thing so well that looking for alternatives feels unreasonable».

Structure of a killer-category product:

1. Focused problem. Not «communication», but «asynchronous team messaging».
2. Low entry barrier. Usable in minutes. No 50-page onboarding.
3. High top-end. Power users find what they need. Not a toy.
4. Composable interface (sect.46 — Lesson 14). API/CLI/web — choose. No lock-in to one way.
5. Network effects or standards effects. The more it's used, the costlier not using it.

Killer category vs market leader:

Market leader — large market share. Killer category — a state where alternatives aren't considered. Microsoft Word — market leader, not killer. Google Search — killer. The difference: for Word, there are rational reasons to choose LibreOffice; for Google, there's no equivalent reason to choose Bing for most tasks.

Strategy for startups:

1. Find a narrow niche. Not «best X», but «only reasonable choice for very specific use case».
2. Make design perfect for that niche. Don't try to be general purpose.
3. Only then expand. After dominating the niche — adjacent expansion.
4. Defend the chosen niche through standards / network / depth. Switching cost must grow over time.

Ties: sect.46 (Lesson 14 — atomic primitive + composition = killer foundation), sect.32 (Whole Product — killer category forms when whole product assembles), sect.31 (Crossing the Chasm — killer status begins with a beachhead).

Eric Raymond, центральная метафора в «The Cathedral and the Bazaar» (1997). Описывает разницу между традиционным closed-source development (cathedral, как Microsoft, GNU emacs до open-source era) и тем, что Linus Torvalds сделал с Linux (bazaar — открытый chaos, который работал лучше cathedral).

Cathedral characteristics:

1. Closed development. Маленькая команда, mentioning of which roadmap controlled tightly.
2. Релизы редкие. Quality gates перед каждым релизом.
3. Bug fixes — это «work of cathedral». Скрытое от users.
4. Design — top-down. Архитектор / архитектурная группа решает.
5. Users — потребители. Feedback асимметричный (запрос идёт вниз, реализация — наверх).

Bazaar characteristics:

1. Открытая разработка. Кто хочет — contributes.
2. Релизы частые. «Release early, release often» — один из ключевых уроков (lesson 7).
3. Bug fixes — это collective work. «Given enough eyeballs, all bugs are shallow» (Linus's Law).
4. Design — emergent. Из тысяч interactions появляется shape.
5. Users — co-developers. Feedback симметричный; иногда user становится contributor.

Когда bazaar выигрывает у cathedral:

— Сложность задачи такая, что одна команда не может покрыть все edge cases.
— Use cases многообразны и непредсказуемы.
— Скорость эволюции важнее качества первого релиза.
— Доступна большая diverse community potential contributor'ов.

Когда cathedral выигрывает:

— Очень узкая задача с предсказуемыми use cases.
— Compliance / regulatory constraints требуют tight controls.
— Aesthetic integrity критична (sect.30 — conceptual integrity сложнее в bazaar).
— Нет community potential contributor'ов (commercial product).

Hybrid models:

Современные крупные open-source проекты — это hybrid:

1. Linux kernel — bazaar для contributions, cathedral для final merge (Linus + lieutenants).
2. Kubernetes — multiple bazaars вокруг SIGs, кафедральная Linux Foundation для top governance.
3. Internal corporate dev с inner sourcing — bazaar внутри company, cathedral interface к outside.

Bazaar не означает chaos — он означает open feedback loops + meritocratic governance.

Применение к корпоративной разработке:

Inner sourcing — это применение bazaar модели внутри company. Любой может contribute в любой repository; reviews проходят через codeowners. Это уменьшает coordination cost и accelerates spread of good code patterns.

Связки: sect.27 (Brooks ×9 — bazaar частично решает coordination problem через rules of meritocracy), sect.30 (Conceptual Integrity — bazaar усложняет это), sect.45-46 (Уроки 13-14 Раймонда — другие правила из той же книги).

Eric Raymond, central metaphor in «The Cathedral and the Bazaar» (1997). Describes the difference between traditional closed-source development (cathedral, like Microsoft or GNU emacs before the open-source era) and what Linus Torvalds did with Linux (bazaar — open chaos that worked better than cathedral).

Cathedral characteristics:

1. Closed development. Small team, roadmap tightly controlled.
2. Rare releases. Quality gates before each release.
3. Bug fixes are «cathedral work». Hidden from users.
4. Design — top-down. Architect / architecture group decides.
5. Users are consumers. Feedback asymmetric (request goes down, implementation goes up).

Bazaar characteristics:

1. Open development. Whoever wants — contributes.
2. Frequent releases. «Release early, release often» — a key lesson (lesson 7).
3. Bug fixes are collective work. «Given enough eyeballs, all bugs are shallow» (Linus's Law).
4. Design — emergent. Shape arises from thousands of interactions.
5. Users are co-developers. Symmetric feedback; sometimes a user becomes a contributor.

When bazaar beats cathedral:

— Task complexity such that one team can't cover all edge cases.
— Diverse and unpredictable use cases.
— Evolution speed matters more than first-release quality.
— Large diverse community of potential contributors available.

When cathedral wins:

— Very narrow task with predictable use cases.
— Compliance / regulatory constraints demand tight controls.
— Aesthetic integrity critical (sect.30 — conceptual integrity is harder in bazaar).
— No community of potential contributors (commercial product).

Hybrid models:

Modern large open-source projects are hybrids:

1. Linux kernel — bazaar for contributions, cathedral for final merge (Linus + lieutenants).
2. Kubernetes — multiple bazaars around SIGs, cathedral Linux Foundation for top governance.
3. Internal corporate dev with inner sourcing — bazaar inside the company, cathedral interface to outside.

Bazaar isn't chaos — it's open feedback loops + meritocratic governance.

Application to corporate development:

Inner sourcing is bazaar applied inside a company. Anyone can contribute to any repository; reviews go through codeowners. This reduces coordination cost and accelerates spread of good code patterns.

Ties: sect.27 (Brooks ×9 — bazaar partially solves coordination problem through meritocracy rules), sect.30 (Conceptual Integrity — bazaar complicates it), sect.45-46 (Raymond's Lessons 13-14).

ADA Engineering culture (Yandex, Avito и ряд других tech-компаний). Pain Index — это попытка квантифицировать operational discomfort команды, превратить тихую жалобу в действенный signal. Метрика — продолжение sect.60 (Health Checks) на operational dimension.

Что измеряет Pain Index:

Композитный score от 0 до 10, собранный из нескольких dimension:

1. On-call burden. Сколько ночных pages, сколько time on-call vs total time.
2. Interrupt rate. Сколько раз в день инженер отвлекается от focus work на urgent ad-hoc.
3. Manual toil. % времени на manual ops vs на actual development.
4. Wait times. CI duration, deploy time, time waiting for reviews, environment readiness.
5. Cognitive load. Subjective rating от инженеров (раз в спринт), сколько mental effort требуется для daily work.
6. Tool friction. Сколько workarounds, сколько «надо помнить специальные шаги», сколько manual data transfer между tools.

Каждая dimension — 0-10. Composite = weighted average.

Operational use:

1. Threshold-based action. Pain Index > 6 на любой dimension в течение 2 спринтов подряд — обязательная investigation, не optional.
2. Trend matters больше abolute value. Pain Index 7, но снижается — лучше, чем Pain Index 5 и растёт.
3. Сравнение между командами. Если у одной команды Pain Index стабильно выше — это сигнал о структурной проблеме (плохой tech debt, понятный к менеджменту distribution).
4. Tie to investment decisions. Не «давайте инвестировать в CI» — а «CI wait time даёт +1.2 к Pain Index; инвестиция X снизит на Y».

Антипаттерны Pain Index:

— Manipulation. Команды занижают, чтобы выглядеть хорошо. Antidote — комбинация subjective + objective sources (logs, не self-report).
— Gaming. Goodhart (sect.9) применим: «снижай Pain Index» → команды учатся избегать ситуаций, повышающих метрику, а не реальной боли.
— Pain как virtue. «Heroism culture»: высокий Pain — это знак работы. Это deeply broken.
— Замер без действия. Pain Index измеряется, отображается на dashboard, но не триггерит investments. Через 2 квартала команды перестают реагировать на anketing.

Связки: sect.21 (HOP — Pain Index это инструмент работы с work-as-done), sect.60 (Health Checks — Pain Index это специализированный health check), sect.70 (TTM·R&R·Legacy·SLA — Pain часто follows из нарушенного R&R balance), sect.9 (Goodhart — gaming risk).

ADA Engineering culture (Yandex, Avito and several other tech companies). Pain Index is an attempt to quantify operational discomfort, turning quiet complaint into an actionable signal. The metric extends sect.60 (Health Checks) along an operational dimension.

What Pain Index measures:

Composite score 0-10, aggregated from several dimensions:

1. On-call burden. How many night pages, on-call time vs total time.
2. Interrupt rate. How many times a day an engineer is pulled from focus work to urgent ad-hoc.
3. Manual toil. % time on manual ops vs actual development.
4. Wait times. CI duration, deploy time, time waiting for reviews, environment readiness.
5. Cognitive load. Subjective rating from engineers (per sprint), how much mental effort daily work demands.
6. Tool friction. How many workarounds, how many «special steps to remember», how much manual data transfer between tools.

Each dimension — 0-10. Composite = weighted average.

Operational use:

1. Threshold-based action. Pain Index > 6 on any dimension for 2 consecutive sprints — mandatory investigation, not optional.
2. Trend matters more than absolute value. Pain Index 7 but decreasing — better than Pain Index 5 and rising.
3. Cross-team comparison. If one team's Pain Index is consistently higher — that's a structural-problem signal (tech debt distribution understandable to management).
4. Tie to investment decisions. Not «let's invest in CI» — «CI wait time adds +1.2 to Pain Index; investment X reduces by Y».

Pain Index anti-patterns:

— Manipulation. Teams under-report to look good. Antidote — combination of subjective + objective sources (logs, not self-report).
— Gaming. Goodhart (sect.9) applies: «reduce Pain Index» → teams learn to avoid situations raising the metric, not real pain.
— Pain as virtue. «Heroism culture»: high pain is a sign of work. Deeply broken.
— Measurement without action. Pain Index measured, dashboard exists, but doesn't trigger investments. In 2 quarters teams stop responding to surveys.

Ties: sect.21 (HOP — Pain Index is a tool for working with work-as-done), sect.60 (Health Checks), sect.70 (TTM·R&R·Legacy·SLA), sect.9 (Goodhart — gaming risk).

ADA Engineering, «Culture of Engineering» framework. Идея фундаментальна: «оптимизировать команду» — бессмысленно без выбора что именно оптимизировать. Эти 4 цели — orthogonal axes, на которых команда позиционируется.

TTM — Time to Market. Скорость от идеи до production. Метрики: lead time, deployment frequency, story-to-prod в спринтах. Оптимизация — упрощение pipeline, parallel work, fewer dependencies.

R&R — Reliability & Resilience. Качество работы системы в production. Метрики: uptime, error rate, MTTR, incident frequency. Оптимизация — testing, observability, graceful degradation, redundancy.

Legacy — Technical Debt Control. Здоровье codebase в долгом плане. Метрики: code complexity, test coverage, refactoring rate, dependency freshness. Оптимизация — refactoring time budget, depreciation policy, architectural reviews.

SLA — Service Level Agreements. Выполнение обязательств перед стейкхолдерами (клиенты, другие команды). Метрики: SLA compliance, promised-vs-delivered ratio. Оптимизация — capacity planning, conservative commitments, escalation paths.

Четыре ловушки одной цели:

1. TTM-only. «Ship fast, fix later». Накапливается legacy debt + R&R деградирует. Через год — система, в которую страшно вносить изменения.
2. R&R-only. «Сначала всё проверим 10 раз». TTM падает; конкуренты выходят с фичами быстрее. Через год — perfect система без пользователей.
3. Legacy-only. «Сначала всё перепишем, потом фичи». TTM = 0 на долгое время; R&R может ухудшиться во время переписывания. Через год — переписанная система без бизнеса.
4. SLA-only. «Соблюдай обязательства любой ценой». TTM падает (под-обещай и пере-доставь), R&R под угрозой (сделать вовремя любой ценой), Legacy не контролируется. Через год — выгоревшая команда, выполнившая SLA.

Operational balance:

1. Явный split capacity. Например: 40% TTM (новые фичи), 30% R&R (reliability work), 20% Legacy (refactoring), 10% SLA (operational commitments). Цифры варьируются под фазу продукта.
2. Регулярные re-balance. Каждый квартал ревью: какая ось горит, где пере-инвестированы. Перераспределение capacity.
3. Owner per axis. На каждую цель — DRI (sect.56). Иначе все 4 размываются.
4. Visibility metrics. Все 4 метрики видны на одном dashboard; trend matters.

Phases of product:

— Early stage (PMF search): TTM dominates (60%+), Legacy низко (10%), R&R соответствует use case.
— Growth: TTM ещё высок (40%), R&R растёт (30%), Legacy начинает (15%), SLA становится формальным (15%).
— Scale: Все 4 балансируются (~25% каждая).
— Mature: Legacy и R&R доминируют; TTM медленнее, но quality высокое.

Связки: sect.69 (Pain Index — высокий Pain часто означает нарушенный balance), sect.16 (Beck's 3X — Explore vs Expand vs Extract диктует другую weights), sect.7 (Price's Law — productive few часто распределяются по axes), sect.71 (Strategy vs Culture).

ADA Engineering, «Culture of Engineering» framework. The idea is fundamental: «optimize the team» is meaningless without choosing what to optimize. These 4 goals are orthogonal axes on which a team positions itself.

TTM — Time to Market. Speed from idea to production. Metrics: lead time, deployment frequency, story-to-prod in sprints. Optimization — pipeline simplification, parallel work, fewer dependencies.

R&R — Reliability & Resilience. Quality of system in production. Metrics: uptime, error rate, MTTR, incident frequency. Optimization — testing, observability, graceful degradation, redundancy.

Legacy — Technical Debt Control. Codebase health long-term. Metrics: code complexity, test coverage, refactoring rate, dependency freshness. Optimization — refactoring time budget, depreciation policy, architectural reviews.

SLA — Service Level Agreements. Fulfilling commitments to stakeholders (clients, other teams). Metrics: SLA compliance, promised-vs-delivered ratio. Optimization — capacity planning, conservative commitments, escalation paths.

Four single-goal traps:

1. TTM-only. «Ship fast, fix later». Legacy debt accumulates + R&R degrades. A year later — a system you're afraid to change.
2. R&R-only. «Let's check everything 10 times first». TTM drops; competitors ship features faster. A year later — perfect system without users.
3. Legacy-only. «Let's rewrite first, then features». TTM = 0 for a long time; R&R may worsen during rewrite. A year later — rewritten system without a business.
4. SLA-only. «Honor commitments at any cost». TTM drops (under-promise and over-deliver), R&R at risk (deliver on time at any cost), Legacy uncontrolled. A year later — burnt-out team that hit its SLA.

Operational balance:

1. Explicit capacity split. E.g.: 40% TTM (new features), 30% R&R (reliability work), 20% Legacy (refactoring), 10% SLA (operational commitments). Numbers vary by product phase.
2. Regular rebalance. Quarterly review: which axis is burning, where over-invested. Capacity reallocation.
3. Owner per axis. Each goal — DRI (sect.56). Otherwise all 4 blur.
4. Visibility metrics. All 4 metrics on one dashboard; trend matters.

Product phases:

— Early stage (PMF search): TTM dominates (60%+), Legacy low (10%), R&R matches use case.
— Growth: TTM still high (40%), R&R rising (30%), Legacy starts (15%), SLA becomes formal (15%).
— Scale: All 4 balanced (~25% each).
— Mature: Legacy and R&R dominate; TTM slower, but quality high.

Ties: sect.69 (Pain Index — high pain often means broken balance), sect.16 (Beck's 3X — Explore vs Expand vs Extract dictates different weights), sect.7 (Price's Law), sect.71 (Strategy vs Culture).

Высказывание приписывается Peter Drucker, операционализировано в engineering culture книг ADA Engineering, SE at Google. Структурное наблюдение: стратегия — это направление, культура — это множитель скорости в этом направлении (положительный или отрицательный).

Что значит «культура побеждает» операционно:

— Стратегия требует quality first. Культура поощряет ship fast. Каждое утро инженер выбирает ship fast.
— Стратегия — collaboration. Культура — heroic individualism. PR'ы — соревнование, не помощь.
— Стратегия — long-term thinking. Культура — quarterly metrics review. Решения короткие.

Что меняет культуру (рычаги Meadows, sect.20+):

1. Что измеряется. Goodhart работает: команда оптимизирует то, что в дашборде.
2. Кого продвигают. Promotion — самый сильный культурный сигнал.
3. Что празднуется. Heroic firefighting vs preventive engineering.
4. Кого нанимают. sect.62 — каждый hire либо усиливает культуру, либо разбавляет.
5. Поведение топ-менеджмента. Команда копирует, не слушает.

Антипаттерн strategy-only: запуск инициативы с offsite, slide deck, kickoff — без изменения метрик, promotion criteria, hiring bar. Через 6 месяцев инициатива забыта, культура осталась.

Связки: sect.9 (Goodhart), sect.62 (Hire by Attitude), sect.57 (Manager as Judge).

The quote is attributed to Peter Drucker, operationalized in engineering culture from ADA Engineering, SE at Google. A structural observation: strategy is direction, culture is the speed multiplier in that direction (positive or negative).

What «culture wins» means operationally:

— Strategy demands quality first. Culture rewards ship fast. Every morning the engineer picks ship fast.
— Strategy — collaboration. Culture — heroic individualism. PRs become competition, not help.
— Strategy — long-term. Culture — quarterly metrics review. Decisions are short.

What changes culture (Meadows leverage points, sect.20+):

1. What's measured. Goodhart applies: the team optimizes what's on the dashboard.
2. Who gets promoted. Promotion is the strongest cultural signal.
3. What's celebrated. Heroic firefighting vs preventive engineering.
4. Who's hired. sect.62 — every hire reinforces or dilutes culture.
5. Top-management behavior. The team copies, doesn't listen.

Strategy-only anti-pattern: launching an initiative with offsite, slide deck, kickoff — without changing metrics, promotion criteria, hiring bar. Six months later the initiative is forgotten, culture intact.

Ties: sect.9 (Goodhart), sect.62 (Hire by Attitude), sect.57 (Manager as Judge).

What You See Is All There Is — bias из «Thinking, Fast and Slow», цитируется Mark Seemann в применении к code reviews и architecture. Структурно: System 1 (быстрое мышление) работает на доступных данных; знание о том, что данных недостаточно, должно поступить от System 2 (медленное мышление) — а System 2 ленива.

Канонические проявления в инженерии:

1. Estimate сложности. Видишь happy path, не видишь edge cases. Estimate ×3.
2. Root cause analysis. Нашёл первую причину, остановился. Это часто proxy, не cause.
3. Code review. Видишь diff, не видишь систему вокруг. Approve.
4. Choosing technology. Сравниваешь по features в документации, не видишь production reality через 18 месяцев.
5. Designing API. Видишь известные use cases, не видишь те, что появятся.

Контрмеры:

— Pre-mortem. «Представь, что проект провалился через полгода — почему?» Заставляет искать невидимые риски.
— Outside view. Найди base rate по похожим проектам, не оценивай каждый раз inside.
— Steel-man. Активно ищи аргументы против своего решения.
— Pause before confidence. «А что я могу не знать?» — обязательный шаг перед commitment.

Связки: sect.12 (Hofstadter — родственный bias), sect.43 (First Principles — против WYSIATI), sect.18 (Hollnagel — work-as-done скрыт от work-as-imagined).

What You See Is All There Is — bias from «Thinking, Fast and Slow», cited by Mark Seemann in application to code reviews and architecture. Structurally: System 1 (fast thinking) works on available data; knowing data is insufficient must come from System 2 (slow thinking) — and System 2 is lazy.

Canonical engineering manifestations:

1. Complexity estimates. You see the happy path, not edge cases. Estimate ×3.
2. Root cause analysis. Found the first cause, stopped. Often a proxy, not the cause.
3. Code review. You see the diff, not the surrounding system. Approve.
4. Choosing technology. Compare by docs features, don't see production reality 18 months out.
5. Designing API. See known use cases, not those that will emerge.

Counter-measures:

— Pre-mortem. «Imagine the project failed in six months — why?» Forces hunting invisible risks.
— Outside view. Find the base rate on similar projects, don't estimate inside each time.
— Steel-man. Actively find arguments against your decision.
— Pause before confidence. «What might I not know?» — mandatory step before commitment.

Ties: sect.12 (Hofstadter — related bias), sect.43 (First Principles — antidote to WYSIATI), sect.18 (Hollnagel — work-as-done is hidden from work-as-imagined).

Источник — Mark Seemann, «Code That Fits in Your Head», структурированный список приоритетов. Тезис: чем дальше от исполнения, тем выше risk drift'а. Тип — встроен в компиляцию, не может soly drift'нуть. Внешний документ — никак не связан с кодом, может рассинхрониться завтра.

Иерархия (от самого истинного к самому ненадёжному):

1. Тип. Если функция возвращает Result<Order> — это контракт. Компилятор не позволит соврать.
2. Имя метода/переменной. Хорошее имя — это документация, которая исполняется. Меняется вместе с кодом.
3. Сам код. Что на самом деле выполняется. Истина в production.
4. Тест. Документирует ожидаемое поведение. Запускается — значит проверяется.
5. Комментарий в коде. Не запускается, но рядом с кодом. Меняется чаще, чем external doc.
6. README · wiki · Confluence. Расположено далеко от кода. drift'ит первым.