Мы с Мэттом сидели друг против друга и беззаботно болтали о технологиях и готовке. Раньше мы были шапочно знакомы по Twitter, где он постил разные кулинарные фото. Я даже стал немного завидовать ему и другим жителям пригородов, их мощным газовым горелкам для воков на заднем дворе. Мэтт выступает в качестве «подопытного» в моем новом проекте. Благодаря ему я смогу понять, интересную ли штуку придумал, или игра не стоит свеч.

– А кем ты работаешь?

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

– А до того?

– Инженер-геолог. Куча горных работ, разные туннели. Гидроэлектростанции. Земляные насыпные плотины – их часто строят рядом с шахтами.

Он рассказал мне о своей старой работе. Его фирму наняли для исследования системы разработки рудника в Британской Колумбии (провинция на западе Канады – Прим. пер.) методом блокового обрушения. Блоковое обрушение – это такой способ разработки шахты, при котором под месторождением роют туннели, чтобы его дестабилизировать. Месторождение медленно обрушается, а руда ссыпается в специальные отводы. «А деньги падают в карман, будто ты их на принтере печатаешь», – добавил Мэт. В чем подвох? Шахта залегала в четырехстах метрах под свалкой токсичных отходов конкурирующей компании. «Может ли статься, что в случае землетрясения отходы затопят шахту и всех умрут?» Мэтту нужно было доказать, что всё в порядке.

Согласитесь, его нынешняя работа – совсем другое дело. «Мой скромный блог куда безопаснее, чем всякие проекты по добыче полезных ископаемых стоимостью в сотни миллионов долларов».

Кажется, моя идея была не так уж плоха…

Инженеры-программисты – это «настоящие» инженеры? Многие из нас так себя называют. Но заслуживаем ли мы этого звания на самом деле? Или просто хотим казаться кем-то важным, стоящим? Это серьезный вопрос, и, как все такие вопросы, он регулярно вызывает споры в Интернете.

Одни говорят, что мы не заслуживаем звания инженеров, потому что живем не по «инженерным стандартам», что нам нужны сертификация, лицензирование и строгое следование проекту. Они предрекают «Грядущий программный апокалипсис», стремясь доказать, что с нами что-то не в порядке.

В другом углу ринга собрались такие люди, как Пит МакБрин и Пол Грэм, которые говорят: да, мы не инженеры, потому что слово «инженерия» не совсем подходит к нашей области. Инженеры работают над проектами предсказуемыми, тщательно подготовленными и спланированными, проработанными согласно строгим требованиям. А программирование динамично, изменчиво, непредсказуемо. Если попытаться применить инженерную практику к программному обеспечению, то софт будет в 10 раз дороже и застрянет где-нибудь в 1970-х.

Долгое время я отказывался называть себя инженером-программистом и считал тех, кто так себя называет, позерами. Но потом я прочел короткий рассказ, критикующий «инженерство», и усомнился в своих принципах. Рассказ назывался «Мост в никуда», он опубликован на сайте Codeless Code. Автор утверждает, что приемы и принципы строительства мостов не применимы к созданию программного обеспечения, так как клиенты ПО могут резко менять свои требования. Это как если бы гравитация вдруг начала работать в обратную сторону: «Предсказуемость мира настоящего инженера вызывает зависть. Но наш мир – это бурный поток, и законы его течения меняются еженедельно. Если мы не будем быстро адаптироваться к непредвиденному, то единственным предсказуемым событием станет наше исчезновение».

Именно тогда я понял одну важную штуку. Сразу обо всех спорщиках из Интернета.

Они никогда не строили мостов.

Никто из этих людей, буквально ни один человек, никогда не работал «настоящим» инженером. В лучшем случае они получили какое-то классическое образование, но все мы знаем, как оно далеко от реальности. Все, что было у участников этих дебатов – их стереотипы. Не я один заметил разницу между инженерией, какой она представляется нам умозрительно, и тем, чем она является на самом деле. Об этом писали и до меня, лучше всех получилось у Глена Вандербурга. Он всерьез читал инженерную литературу, чтобы прочувствовать разницу между инженерией и разработкой ПО. Но мне хотелось бы пойти еще дальше.

Раз уж я взялся сравнивать разработку ПО с «настоящей» инженерией, то мне нужно было поговорить с «настоящими» инженерами. Подумав как следует, я пришел к выводу, что, хоть «настоящие» инженеры и могут в красках рассказать мне о своей профессии, они не знают, чем их работа отличается от моей. Получается, мы будем по очереди делать голословные заявления, не имея каких-либо доказательств. Ничего не зная о специфике работы собеседника. Даже если «настоящие» инженеры используют какое-то программное обеспечение в своей повседневной работе, это не то же самое, что разрабатывать ПО. Только человек, который занимался и разработкой ПО, и «настоящей» инженерией, может объективно говорить о различиях между подходами.

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

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

А в чем вопрос?

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

Неприятие «программной инженерии» происходит из двух источников. Во-первых, гейткиперы (Автор имеет в виду теорию гейткипинга за авторством Курта Левина, подробнее здесь. – прим. переводчика). Если поначалу мы называли себя программистами и разработчиками, то после 1985 г. все больше и больше людей стали использовать словосочетание «инженер-программист». Определение раздулось, как таблица в базе данных, и теперь его используют по поводу и без, не соотнося с какими-то стандартами. Во-вторых, последователи экстремального программирования и Agile – новых течений в области программного обеспечения 90-х и начала 00-х годов – отказались от применения стандартных методов управления проектами в разработке программного обеспечения. Для них инженерия представлялась чем-то устаревшим, несовместимым с новыми способами разработки ПО. Программная инженерия была объявлена устаревшей и тупиковой.

Оба этих явления происходят от разных коннотаций понятия «инженерия». В случае с гейткиперами – это положительные коннотации, которых, по их мнению, мы не достойны. Для приверженцев новых, якобы «кустарных», методов программирования – это негативный балласт, который мы, по их мнению, должны отринуть. Оба этих суждения подкрепляются аргументами, основанными на восприятии программирования как процесса. Это хорошо для отстаивания своей точки зрения, но не помогает понять, чем программирование является сейчас. Их планы решения задачи основаны на том, что они сами не понимают. Ни один из спорящих о том, имеет ли «программная инженерия» отношение к собственно инженерии, не работал инженером.

Распространенные заблуждения

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

Я попросил людей перечислить конкретные качества, «инженерно-специфичных» занятий. Вот наиболее распространенные ответы:

• создание чего-то комплексного в команде;

• создание чего-то материального;

• изготовление чего-то в соответствии со строгой спецификацией, со строгими принципами;

• использование математических принципов при проектировании;

• высокая цена ошибки, вплоть до человеческих жертв;

• сертификация и лицензирование.

Первый пункт списка слишком пространен: почти все профессии предполагают командную работу над чем-то комплексным. Это не специфика «инженерной деятельности». Второй пункт – слишком узкий: не все формы инженерии приводят к созданию чего-то материального. Например, промышленная инженерия. Третий пункт я отдельно рассмотрю в следующей статье.

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

Инженерия – это математика

Здесь все просто. Утверждение состоит в том, что инженерия сопряжена в первую очередь с применением высшей математики, в то время как в программировании она пригождается очень редко. Путаница происходит из-за непонимания того, что такое математика. Большая часть математики, которую используют, например, инженеры-механики, – это бесконечные расчеты. Исчисление, тригонометрия и дифференциальные уравнения – то, что большинство изучает в средней школе. Это и становится для них «математикой».

В программировании мы всем этим не пользуемся, что заставляет думать, что мы не используем математику вовсе. Но мы применяем дискретную математику, в которой мы имеем дело исключительно с конечными множествами. Сюда входят также теория графов, логика и комбинаторика. Можно не осознавать, что ты их используешь, но это так. Они настолько укоренились в программировании, что просто не воспринимаются как математика! Фактически большую часть информатики можно рассматривать как ветвь математики. Каждый раз, когда ты упрощаешь условие или прорабатываешь сложность работы алгоритма, ты используешь математику. То есть отсутствие интегралов не означает отсутствия математики.

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

Инженерия – это высокие риски

Не помню точно, когда во мне рухнул этот стереотип. Возможно, во время беседы с Майком, бывшим инженером-механиком, который сейчас разрабатывает датчики для нужд гляциологии. В одном из его последних перед сменой работы проектов он был членом команды, разрабатывающей секретное медицинское устройство. Большая часть работы прошла гладко, но затем случился стопор: «Больше всего хлопот нам доставила ручка – изогнутый кусок проволоки, залитый пластиком. Нужно было правильно согнуть проволоку и покрыть пластиком этот блестящий кусок анодированной алюминиевой проволоки. [...] Именно на это ушло три месяца».

Да, три месяца были посвящены тому, чтобы сделать ручку прибора.

Это не значит, что работа была неважной. Но это значит, что инженеры потратили много времени на то, что несет низкие риски или не является критичным с точки зрения безопасности. Если подумать, то это не должно было меня удивлять. Мир огромен, инженеров в нем невероятно много. Да, кто-то проектирует мосты. Но кто-то также должен создавать все те мелочи, которые мы используем в повседневной жизни. Большая часть инженерных изысканий в этой сфере не требует больших затрат и не влечет за собой больших последствий. Точно так же, как и в мире разработки ПО.

«Есть огромная разница между тем, делаешь ли ты корпус для Bluetooth-колонок, наподобие тех, что стоят у меня на столе, или собираешь шасси для Boeing 737. Ты используешь одни и те же инструменты, но подходы кардинально отличаются», – Натан (механик).

«Но все равно есть вещи, которые приводят к гибели людей!» Но ровно то же самое можно сказать и о программном обеспечении. Целочисленное переполнение в программе Intrado привело к тому, что служба 911 в течение нескольких часов была недоступна миллионам людей. Предвзятый алгоритм несправедливо отправлял людей в тюрьму. Как и в «настоящей» инженерии, существует широкий спектр ПО, которое если и не убьет людей, то приведет к миллионным убыткам. Это может быть что угодно, начиная от падения Amazon и заканчивая крашами игры.

Инженеры и лицензирование

Самое популярное утверждение. Действительно, есть разница между частным плотником и лицензированным инженером. Точно так же можно вести медицинскую практику на дому, не будучи при этом дипломированным врачом. То же самое происходит и в мире разработки ПО – без лицензий мы не инженеры-программисты. В Канаде даже нельзя называть себя «инженером-программистом», если у тебя нет аккредитации!

При этом примерно у половины инженеров, которых я опросил, не было лицензии, но все равно они считались профессионалами среди коллег. У них не было «сертификации», но были навыки.

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

Вот в чем проблема: лицензии – это социально-политический конструкт, а не естественный. Обществу нужно лицензирование по причинам в равной степени политическим и техническим. Для наглядности давайте рассмотрим некоторые моменты из истории лицензирования в США.

Еще в 1906 г. ни один штат в США не требовал лицензии для реализации инженерных проектов. Первым стал Вайоминг, где ввели политику лицензирования, исключительно потому, что ирригационные проекты постоянно подрывали бюджет. Они предположили, что аккредитованные инженеры смогут дать более точную оценку стоимости проекта. Потребовалось еще 40 лет, чтобы все пятьдесят штатов присоединились к этой политике.

Получается, что лицензирование – вещь не федеральная, это требование штатов. Помимо всего прочего, лицензия, полученная, например, в Техасе, может быть недействительна в другом штате, и, чтобы иметь возможность практиковать в Калифорнии, придется пройти специальную процедуру. Вот такое «взаимное признание».

Несмотря на то, что лицензирование изначально было задумано для сокращения издержек, так быстро распространилось оно совершенно из-за других причин. Регламенты написаны кровью. Любая сфера становится регулируемой, когда отсутствие контроля начинает приводить к гибели людей. Пока в мире ПО не появилось столь же серьезных и при этом распространенных рисков, никто не будет всерьез заниматься лицензированием специалистов. В тех же сферах, где плохое программное обеспечение убивало людей, например, в случае с Therac-25 или в мире авиции, регулирование присутствует. Приведет ли это к более широким лицензионным требованиям к инженерам-программистам, пока неизвестно.

Можно возразить, что работать без лицензии аморально. И я с этим солидарен. Но это аргумент нормативный, а не позитивный. Аргументация типа: «Все спецы должны быть лицензированы или они не спецы вовсе», – слишком общая, пространная. Это попытка ответить на вопрос: «Должны ли мы стремиться соответствовать более высоким стандартам?». Но сейчас речь не о том. Меня не волнует, куда мы должны двигаться. Я хочу понять, где мы уже находимся. А являемся мы сертифицированными инженерами или нет, не имеет никакого отношения к тому, хорошие ли мы инженеры.

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

Истина

В итоге мы вернулись к тому, с чего начали: нет никаких признаков, указав на которые, можно было бы четко сказать: «Это – инженерия, а это – нет». Получилась «языковая игра» Витгенштейна: человеческие представления не укладываются в точные определения. Стоит оперировать словом «инженерия» для описания целого семейства родственных понятий. И судить о принадлежности к нему людей по принципу схожести ряда качеств, а не их разности. Другими словами, «инженерия» – это то, «чем занимаются инженеры». Что-то становится «инженерным», если с этим согласно достаточное количество инженеров.

Рассмотрим химическую инженерию. Она не похожа на промышленную, строительную или электротехническую. Инженеры-химики создают процессы для масштабного производства продуктов, часто используя эксперименты и итерации. Но никто не станет отрицать, что это инженерия. Химическая инженерия зародилась в конце 1800-х годов, до того, как в Штатах появилось лицензирование для инженеров. Если бы химическая инженерия началась сейчас, люди отказались бы называть ее инженерией. И они были бы неправы.

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

Из 17 кроссоверов, с которыми я разговаривал, 15 ответили «да».

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

«Даже владельцы продуктов и менеджеры проектов в некотором смысле являются инженерами [...] каждый в какой-то степени является своего рода инженером», – Кейт (химик).

Нет смысла противопоставлять «настоящую» инженерию «программной». В дальнейшем я буду вместо этого использовать термин trad-инженерия (От слова traditional, «традиционный» – прим. переводчика).

Ремесло против инженерии

«Я отвечу несколько иначе. Не каждый разработчик ПО – инженер-программист, точно так же, как не каждый человек, работающий в строительстве, – инженер. Инженер – это очень специфический набор навыков. [...] Программная инженерия – это мастерство, плюс понимание процессов, циклов, последствий и всего того, о чем ты должен знать и чего избегать», – Дон (механик и химик).

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

Некоторые люди предлагают словосочетание «мастер-программист». Этот термин взят из книги Software Craftsmanship: The New Imperative, написанной Питом МакБрином. В ней он утверждает, что программирование не является разновидностью инженерии, будучи гораздо более свободным, творческим и гибким процессом. Для него мы не рабочие у станка, а ремесленники, художники. Люди, которые гордятся своим ремеслом и независимостью: «Разработка программного обеспечения – это столкновение с неизвестным. Притом процесс производства программного обеспечения тривиально прост – достаточно скопировать диск. Определение «программная инженерия» не работает, потому что мы понимаем производство – механическую работу – гораздо лучше, чем разработку – труд умственный».

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

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

Я считаю, что все, что МакБрин писал о создании программного обеспечения, достаточно разумно: оно непредсказуемо и сильно зависит от личности создателя. В чем он ошибается, так это в предположении, что в инженерии все не так. Инженерия гораздо богаче, креативнее и художественнее, чем он думает. Он, в конце концов, – не trad-инженер, конечно, его взгляд несовершенен.

Итак, вот мое окончательное мнение. На нем я остановился, объединив все проведенные интервью, и оно не обязательно отражает мнение опрошенных мною кроссоверов. Изначально я думал, что программная инженерия – это не совсем инженерия, что может и было несколько человек, которые могли бы причислить себя к таковым, но большинство из нас не дотягивают до этого уровня. Я до сих пор считаю, что большинство из нас не являются инженерами, потому что мы работаем в областях, которые люди не считают инженерными. Большинство людей не считают веб-сайт «инженерным» произведением. НО между «разработкой программного обеспечения» и «инженерией программного обеспечения» существует гораздо меньший разрыв, чем, например, между «электриком» и «инженером-электриком. Большинство могут легко для себя перейти из «программирования» в «программную инженерию», даже переучиваться не нужно. От инженерии нас отделяют обстоятельства, а не сама ее суть, и мы вольны выбирать, как именно преодолеть этот разрыв.

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

Вторая часть, «Мы не особенные», доступна здесь.

Спасибо Гленну Вандербургу, Челси Трой, Уиллу Крафту и Дэну Луу за их отзывы и предложения, а также всем инженерам, у которых я брал интервью.

Приложение

Методология

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

Распределение по специальностям следующее:

• инженеры-строители работают над зданиями (один респондент, был классическим инженером-строителем, один специализировался на проектировании шахт, а двое работали на нефтяных вышках);

• инженеры-механики проектируют машины;

• инженеры-электрики проектируют схемы и электронику (двое разрабатывали чипсеты, а один работал над подводной лодкой;

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

• инженеры-технологи создают целостные системы и процедуры в той или иной отрасли (дата центры, интеграция децентрализованных систем управления воздушным движением).

Список получился обширный, охватывающий множество специальностей. Большинство инженеров работают в какой-либо подобласти специальности, например, в автомобилестроении или схемотехнике. Также есть некоторые области инженерии, которые я не смог охватить в своих интервью. К ним относятся аэрокосмическая и ядерная физика. Я подозреваю (подозреваю), что аэрокосмическая отрасль похожа на машиностроение, а ядерная – на гражданское строительство. Но, тем не менее, это остается угрозой валидности моего исследования.

Две другие угрозы достоверности моей работы – это географическое расположение и тип кроссоверов: большинство опрошенных находились либо в США, либо в Великобритании, а остальные – в странах ЕС или Канаде. Мне не удалось взять интервью ни у кого из Латинской Америки, Южной Америки, Африки или Азии. Все, с кем я говорил, переходили из области традиционной инженерии в область программной инженерии. Мне не удалось найти никого, кто сделал бы обратный переход.