Мы не особенные

Вторая часть проекта Хиллела Уэйна (Hillel Wayne) о переходе между профессиями, опубликованная в январе 2021 года. В основе всех трёх эссе лежит серия интервью с людьми, которые сначала работали традиционными инженерами - механиками, электриками, строителями, химиками, разработчиками микросхем, - а затем перешли в программирование. Это делает их единственными, кто может сравнивать области на личном опыте, а не опираясь на стереотипы. В первой части исследовалось, являются ли программисты настоящими инженерами. Здесь ставится противоположный вопрос: отличается ли разработка ПО от остальной инженерии по существу. Ответ: она отличается в трёх конкретных вещах и полностью совпадает в большинстве тех пунктов, о которых принято говорить. В artisanal-programmer-label используется вывод проекта о том, что многие пишущие код люди не занимаются программной инженерией, и переносится на разделение эпохи ИИ, хотя сами интервью состоялись задолго до него.

Текст открывается парой эпиграфов, которые укладывают весь аргумент в две строчки. "Никому и в голову не придёт двигать начальную или конечную точку моста прямо посреди стройки" от Джастина Кейва (Justin Cave). И следом цитата анонимного респондента: "Мне приходилось двигать мост".

Скорлупа фундука

Первая история - про Карла (Carl), инженера по верификации в машиностроении, проверявшего уровень вибрации на нефтяных платформах. Люди живут на платформах неделями, и выше определённого порога вибрации они не могут спать; платформы проектируют так, чтобы оставаться ниже этой границы, но проект и готовая конструкция расходятся. Объясняя, как ищут нефть, Карл упомянул добавки, которые закачивают в скважину - "вроде кислоты или скорлупы фундука", - и Уэйн его остановил.

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

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

Зачем заявлять об отличиях

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

Он видит в этом защитный механизм. Если разработка ПО действительно отличается от традиционной инженерии, то вполне нормально, что мы не инженеры. Мы не планируем всё заранее, но лишь потому, что требования у нас меняются быстрее. Мы не применяем инженерные методы, потому что и не должны. В качестве примера он приводит движение NoEstimates: оценки в разработке делать трудно - якобы в отличие от всех остальных сфер, - поэтому давайте вообще от них откажемся.

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

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

Waterfall и Agile

Расхожая легенда гласит: Уинстон Ройс (Winston Royce) придумал Waterfall в 1970 году, чтобы скопировать то, как настоящие инженеры строят здания; эта модель требует строгой последовательности фаз; для разработки ПО она не годится, поскольку требования меняются, а заказчики сами не знают, чего хотят; и Манифест Agile 2001 года отверг этот подход. Уэйн называет эту историю скорее вымыслом, чем правдой. Waterfall никогда не был настолько жёстким, как принято помнить, и не был повсеместным: большинство разработчиков в 1970-х и 1980-х работали ситуативно либо по одной из многочисленных популярных тогда инкрементальных моделей вроде Spiral Model и V-Model. Agile стал естественным продолжением существовавших тенденций, а не революционным разрывом.

Ключевой тезис несостоятелен и сам по себе. Традиционные инженеры действительно больше проектируют на ранних этапах и тратят больше времени на отдельное тестирование, но это диктуется экономикой, а не догмой: когда итерации долгие и дорогие, планировать их заранее выгодно. Майк (Mike), инженер-электронщик, о печатных платах: "Обычное дело, когда с первого раза ничего не работает. Приходится переделывать, отправлять на завод и делать заново. И ты знаешь, что это стоит тебе ещё сколько-то тысяч фунтов и ещё две недели по графику". Это итерации с ценником, а не запрет на фазовые переходы.

Практики в духе Agile встречаются повсюду, стоит только присмотреться. Новый австрийский метод строительства тоннелей строит тоннели через итеративную разработку с возможностью для импровизации. В Handbook of Industrial Engineering подчёркивается междисциплинарное взаимодействие и быстрая обратная связь от заказчика. Даже гражданское строительство - самый похожий на Waterfall кандидат из всех - с началом стройки сдвигается в сторону адаптации, потому что проблемы на площадке требуют открытой коммуникации.

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

Предсказуемость

Первая цитата в этом разделе состоит не из слов. Это "Смех", приписанный Доун (Dawn), Мэтту (Matt), Стиву (Steve), Майку (Mike), Мэту (Mat) и Ещё Одному Мэтту (Another Matt).

Диагноз Уэйна: со стороны мы видим результаты инженерного процесса, а не сам процесс. Мы не видим трения, превышения смет или задержек из-за того, что стену построили на пару сантиметров левее, чем нужно, или ключевой поставщик обанкротился. Считать, будто разработка ПО исключительно непредсказуема, - по его выражению, особая форма высокомерия.

Аргумент про постоянную смену инструментов получает прямой контрпример от Стива, разработчика микросхем: "В мире программирования люди думают: 'Какой там у нас новый сборщик для JavaScript в этом месяце'. В мире 'железа' думают: 'Что нам в этом месяце могут предложить фабрики по производству кремния'. Если у фабрики появилось новое оборудование для производства чипов, ваши планы меняются. Не так стремительно, как меняются библиотеки, но всё равно достаточно быстро". Меньше изменений - не значит их отсутствие, да и чехарда инструментов - лишь один источник непредсказуемости среди многих. Смена прав на земельные участки прямо посреди стройки. Внезапный и бесповоротный отказ отработанных процедур. Новые открытия в самом разгаре разработки. Закладка фундамента моста, где выясняется, что именно этот конкретный грунт замерзает так, что при землетрясении он слишком сильно разжижается, - и возврат к чертёжной доске.

"Код - это проект"

Самую сильную формулировку этого тезиса Уэйну дал Ник Коглан (Nick Coghlan), и его опыт придаёт словам вес: один из основных разработчиков CPython, а до того - инженер по системной интеграции в Boeing, координировавший независимые команды, строившие самолёт, систему управления воздушным движением и антенную решётку, чтобы состыковать их интерфейсы. Он называл это "дипломатическим стилем системной архитектуры" и видел в формуле "программный код и есть проект" главное отличие той работы от своей нынешней. Он также объяснил исторический контекст лозунга: это была реакция на людей, веривших, что достаточно нарисовать красивую модель на UML и сгенерировать из неё код, как всё сразу заработает.

Другие инженеры с этим категорически не согласились. Один разработчик микросхем заявил, что проектированием является всё, от первых схем процессора до выхода чипов с фабрики; само производство - простая часть, ведь проект отдают на фабрику и получают чипы обратно. Вот только чипы возвращаются с дефектами, а значит, проект меняется. Инженеры-механики чувствовали это особенно остро, и у Майка для этого было специальное слово - "fettling" (доводка): подгонка проекта под мелкие огрехи процесса сборки. Каждое физическое воплощение меняет проект, что в свою очередь меняет дальнейшую сборку.

Уэйн указывает и на вторую проблему: понятие "проект" (design) не имеет чётких границ. Архитектурный обзор, формальная спецификация, подробные чертежи? Планы моста содержат множество слоёв фрактальной детализации. А если код - это проект, то что тогда является формальной спецификацией для самого кода? Ближайший современный ответ базы знаний - это specsmaxxing и acceptance-criteria-ids, где пронумерованные критерии приёмки выступают уровнем над кодом, к которому код отсылает. Более глубокий ответ даёт концепция programming-as-theory-building: тезис Наура (Naur) о том, что настоящий продукт - это общая ментальная модель команды, а код, документация и тесты - лишь обслуживающие её артефакты. Это переосмысляет сам вопрос "проектирование против реализации" как ложную дихотомию.

Строгость

Мэт о заявлении, что традиционная инженерия аккуратнее: "В разработке программ в миллион миллионов раз больше сдержек и противовесов, чем в традиционной инженерии. [...] Когда кто-то твитит про ужасы работы с Excel *смех*, у меня найдутся потрясающие кошмары про Excel [...] бывают дни, когда я поражаюсь, почему небоскрёбы не падают каждый день, а самолёты не бьются".

Уэйн делает здесь два хода. Во-первых, меньшая строгость разработки ПО отчасти представляет собой рациональный компромисс, а не культурный изъян. Ник объяснил это разницей в проверке предположений: "Наступает момент, когда самый простой способ проверить гипотезу - просто пойти и сделать это". Дешёвый эмпиризм сам по себе служит источником строгости, доступным в разработке ПО так, как он недоступен в области, где эксперимент стоит две недели и 1000 фунтов.

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

Три настоящих отличия

Предсказуемость поведения

Нейтан (Nathan): "Программное обеспечение полностью синтезировано. Оно ограничено исключительно логикой. Оно не изнашивается, как пружина, понимаете? Оно просто делает то, что должно делать. Единственное, что на самом деле может пойти не так, - это спецификации". Если дать кому-то функцию сортировки, от неё ждут сортировки - а не того, что она отсортирует нормальный список в 95% случаев, что было бы абсурдом. С физическими материалами всё устроено иначе. Цветовые полосы резистора кодируют номинальное сопротивление и допуск; золотая полоса означает ±5%, так что в партии номиналом 5600 Ом будут детали и на 5320, и на 5880 Ом, и единственный способ узнать реальное значение - проверить каждый резистор. И это ещё до износа и влияния температуры. Другой любимый пример Уэйна - компания Fastenal, производящая крепёж: на её инженерных страницах висят предупреждения о том, что нельзя вкручивать винты из нержавеющей стали в алюминиевую пластину. "В программной инженерии ничего подобного нет".

Скорость

Мэтт, инженер-химик: "Код - это спецификация того, как должно работать 'железо'. В традиционной инженерии нам пришлось бы проделать всю ту же работу по согласованию спецификации, но потом нужно ждать, пока фабрика или цех закончат собирать эту чёртову штуку. Затем нам пришлось бы сидеть и монтировать её - либо самим, либо нанимать людей. А потом ещё несколько недель тестировать, работает она или нет". Несколько инженеров описывали изменения, имеющие измеримую цену: каждая правка стоила 5000 долларов из бюджета. Уэйн может изменить код и прогнать тесты за секунды. Самый близкий аналог, который он вообще нашёл, был в химической инженерии: Раджа (Raja) каждое утро приходил на работу и смотрел, что пошло не так за ночь; минутный цикл обратной связи неслыхан даже для самых быстрых некомпьютерных областей.

У этого отличия есть и тёмная сторона, о которой Уэйн говорит прямо. Из-за того что разработка ПО итерирует быстрее, другие дисциплины перекладывают на неё компенсацию физических проблем. Майк: "Программиста зажимает остальная команда. Обычно его просят спасти всех остальных. Если что-то не совсем сходится в электронике или механике, часто это можно обойти программным костылём". Катастрофа 737 MAX - случай, когда такой подход привёл к гибели людей. В двух крушениях 2019 года погибло более 300 человек, и расследование возложило вину на ошибку в MCAS, автоматизированной системе управления полётом. Но MCAS появилась только потому, что в Boeing слишком поздно обнаружили проблемы с аэродинамическим профилем и решили устранить традиционную проблему программной "заплаткой". За разворот этой же асимметрии выступает концепция slow-software-high-latency: теперь, когда время сборки больше не отражает важность задачи, критической инфраструктуре требуется осознанно возвращать барьеры и задержки.

Ограничения

Стив о согласовании бюджета времени для чипа: "У них есть бюджет времени [на чип], у вас есть бюджет времени, и вы говорите: 'Я немного не укладываюсь. У вас нет там запаса? Можно мне кусочек наносекунды?'" В каждом интервью сквозила тема жёстких физических ограничений: достаточно лёгкий, достаточно прочный, достаточно холодный - некая известная величина, которую нужно максимизировать или минимизировать. В разработке ПО тоже есть ограничения: уместиться в память микроконтроллера, ответить ровно за 10 тактов, не превысить лимит запросов к API. Но программные ограничения обычно мягкие. Превышать их плохо, и чем дальше, тем хуже, но границу можно размыть в обмен на скорость разработки или упрощение алгоритма. Слишком широкий ящик просто не пройдёт в дверь, и никакие рассуждения о компромиссах этого не изменят.

Команде Карла однажды потребовалось установить шнековый конвейер на нефтяной платформе, и оказалось, что он на пару дюймов выше помещения. Уменьшить оборудование они не могли, поднять потолок при четырёх этажах сверху - тоже. Поэтому они прорезали дыру в потолке, просунули оборудование и построили короб вокруг отверстия на верхнем этаже, чтобы никто не споткнулся. Эта дыра теперь навсегда стала частью конструкции платформы, и с ней придётся считаться при любых будущих переделках. Отсюда вытекает четвёртое отличие, которое Уэйн скорее выводит из рассуждений, чем выносит в отдельный список: программисты могут отменить свои костыли, а традиционные инженеры - нет. Концепция disposable-code - современная версия этого преимущества: когда код настолько дёшев, что его можно выбросить, меняется само понимание того, за какие проекты вообще стоит браться.

Быть другим - не значит быть особенным

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

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

Он воспринимает этот вывод как хорошую новость. Если разработка ПО не уникальна, ей есть чему поучиться у других дисциплин, а им есть чему поучиться у программирования. Этому посвящена третья часть - What Engineering Can Teach (and Learn from) Us.

Эссе выступает прямым вызовом традиции No Silver Bullet, выводящей аргументы из фундаментальных свойств программного обеспечения. Брукс (Brooks) связывал сложность разработки с такими свойствами, как сложность, согласуемость, изменчивость и незримость, считая их неотъемлемой природой среды. Интервью Уэйна показывают, что по крайней мере изменчивость и согласуемость - это обычные условия любой инженерной работы, а не родовая травма программирования, и что действительно неотъемлемыми являются лишь три выделенных им свойства. Предсказуемость поведения, скорость и жёсткость ограничений - это свойства материала, а не зрелости профессии или её самоощущения.