Are we really engineers?

Сравнения между традиционными инженерными областями и разработкой ПО часто делаются людьми, которые имели опыт работы либо только разработчиками, либо только инженерами.

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

Что похожего

• Костыли есть везде и во всех дисциплинах – что-то делается в последний момент, наспех, "чтобы работало", отличие софта в том, что их часто легче потом убрать (да, все знают про баги, которые никто никогда не исправит, потому что от них уже работоспособность других систем сверху зависит, но все же это попроще будет, чем в основании здания что-то изменить)
• Вера разработчиков в правильность и отлаженность работы традиционных инженеров – миф. В качестве примеров приводится строительство мостов, которым человечество занимается кучу времени, и несмотря на это, относительно недавно, в 1870-х, число ежегодных случаев обрушений мостов было больше 40 в год, в 1880-х в сумме – порядка 200 случаев, или каждый четвертый построенный мост (статистика по штатам, полагаю)
• Стабильность окружение, в котором происходит работа – тоже миф, в качестве примера приводятся частые изменения законодательства, которое влияло на проект по уборке зараженной почвы, или постоянные изменения в характеристиках микросхем, которые фабрика производитель давала компании-заказчику для тестирования.

Что разного

• Объекты, которыми манипулирует разработчик, намного более постоянны в своем поведении по сравнению с объектами физического мира. В качестве примера используется простой фрагмент кода на Python, который будет вести себя примерно одинаково на какой-бы машине его не запустили, и настоящий физический резистор, чьи показатели всегда носят примерное значение, с погрешностью, даже в том случае, когда это резисторы одной модели, из одной партии, и т.п.
• Отсутствие фазы физического производства, которая добавляет большое время ожидания и повышает цену ошибки при проектировании. Каждая область традиционной инженерии была бы рада иметь возможность пробовать разные варианты с такой же скоростью, как ПО.
• Строгость ограничений. В подавляющем большинстве приложений нарушение ресурсных, или временных ограничений не приводит к заметным проблемам (очевидно, кроме областей, где жесткий real-time, прошивки промышленного оборудования, гейм-дев, и подобных) – если алгоритм отработает на 10 миллисекунд дольше, или займет в памяти на несколько килобайт больше обычно катастрофы не происходит.
• В разработке софта намного больше открытых конференций, которые не привязаны к конкретному вендору, или ассоциации, которые инженеры отрасли посещают потому что сами того хотят, а не потому что их послал работодатель, чтобы посмотреть, что поставщики придумали нового.

Исследование еще не закончено и продолжается (будет больше интервью и более развернутое описание результата).

Прямое сравнение начинается на отметке в 15:00, до этого идут рассуждения о том, что такое инженерная дисциплина в принципе.