Понимает ли ваш супруг, как вы думаете?
Инженерия — это аналитическая профессия, в которой, если все сделано правильно, все может быть проверено холодным расчетом. Это данность. Не имеет значения, что вы думаете о чем-то, важен только результат.
Недавнее статья Малкольма Гладуэлла в Нью-Йоркер поднимает этот вопрос. В ней обсуждается роль инженеров в автомобильной службе отзыва. Помните катастрофу Пинто? Столкновения сзади может превратить автомобиль в огненный шар. Что не так с этими инженерами?
Оказывается, числа просто не поддерживают страстные крики о переменах. Большое дело, которое было инициировано, когда три девочки-подростка погибли, когда их Пинто сгорел, выиграл Ford.
Статья дает не относящиеся к инженерам превосходное понимание, как мы думаем, как мы принимаем решения, и что еще более важно, как мы смотрим на мир. Она рисует разительный контраст образа мысли людей, ориентированных на число, и многих других, которые принимают решения, основанные на том, как они себя чувствуют.
Конечно, иногда наши аналитические стороны не всегда уместны. Когда мы растили детей, моя жена спросила, почему я всегда думал о том, что может пойти с ними не так. Я ответил: «Я тренировался в анализе худшего случая.»
Я EE, как и многие из людей прошивки, провел последние четыре десятилетия в зазоре между проектированием схем и написанием кода для поддержки этих схем. Аппаратных сторона не прощает эмоций или какие-либо идей заставить электроны двигаться не в точности так, как предсказано теорией. Что касается программного обеспечения, оно застыло в фазе «но это работает?».
В аппаратуре мы имеем совокупность знаний. Закон Ома. Законы Максвелла. Физика транзисторов. Мы можем проанализировать HFE и другие параметры, чтобы предсказать передаточную функцию, и можно вычислить Q и резонансную частоту при создании колебательного контура, который соответствует определенным требованиям.
Мир программное обеспечение искажен. Прогнозировать трудно. Простотой вопрос — как долго это подпрограмма обработки прерываний, написанная на С, будет выполняться? Большинство из нас не может это предсказать. К счастью, это можно измерить. К сожалению, немногие это делают. Как перевести требования в размер необходимого флэша? Как можно предсказать размер стека или кучи?
В оборудовании мы можем проанализировать нештатные ситуации. Экстремальные температуры, допуски и посадки, сопряженные размеры — все это понятно математически.
Программное обеспечение не слишком понятно. Недостатки скрыты, проявляясь в самых неожиданных местах. Бурю прерываний трудно анализировать. Управление задачами не является детерминированным.
Тогда появляются фичи. Они несутся через программное обеспечение, как пламя пожара в Калифорнии. Редко они рассматриваются в инженерном стандарте — который является холодным, жестким анализом. К сожалению, программное обеспечение процессов очень трудно изучать. Академическая литература полна статей о разных идеях, но подавляющее большинство из них связаны с экспериментами, использующими крошечные кодовую базу, созданную несколькими разработчиков, среди которых в основном студенты с небольшим опытом, и, конечно, не в реальном мире. Инженеры по праву скептически смотрят на выводы из этих игрушечных экспериментов.
Тем не менее, у нас есть много данных, которые большая часть сообщества в программной инженерии не знает.
Что является лучшим способом для разработки кода? Этот вопрос, наверное, даже не имеет смысла, учитывая широкий спектр приложений, постоянно создаваемых. Программа, которая будет использоваться одним человеком дважды, имеет совсем другие потребности, чем та, что управляет двигателями на A380.
Рассмотрим agile-сообщество. Есть десятки agile методов. Которые из них работают? Какой из них лучше? Никто не знает. На самом деле, мало достоверных данных (за пределами игрушечных экспериментов) об эффективности agile методов против других подходов. Это определенно не повод выкидывать agile, как я считаю, (из за отсутствия аналитических данных) некоторые из agile идей просто блестящи.
Некоторые люди говорят, что, конечно, нам не хватает данных о agile, но это справедливо и для других методов. В это много правды, поскольку в EE были столетия для развития теории, чтобы извлечь выгоду из работ Георга Ома и других. Программное обеспечение относительно новая концепция. Мы по-прежнему нуждаемся в Теории Программного Обеспечения Всего.
Но полагаю, можно по-новому сформулировать эти вопросы. Например: «Какие два самых эффективных способа уменьшить ошибки и ускорить разработку?».
Интересно, какой будет ваш ответ.
Все очень просто: формальные проверки и статический анализ. Почему? У нас есть данные. На самом деле, у нас есть десятки тысяч точек данных. Один источник «The Economics of Software Quality» by Capers Jones and Olivier Bonsignour, но есть многие других.
Мы знаем, что цикломатическое сложность — это, на самом деле, хороший способ измерить аспекты эффективности тестирования.
Мы знаем, на самом деле, что средняя команда программистов не удаляет 15% предварительно внесенных ошибок. Мы знаем, что команда прошивки пропускает треть от внесенных ошибок.
У нас есть данные, часть закона Ома для разработки программного обеспечения. Тем не менее, в мире встраиваемых систем лишь около 2% команд используют эти данные для управления их методами разработки.
Я считаю, что есть много данных, и я призываю разработчиков использовать их, и применять результаты в своей повседневной работе.
Эдвардс Деминг сказал лучше всех: «В Бога мы верим, все другое требует данных».
