Почему ИТ-индустрия не может реализовать крупные, безошибочные проекты так быстро, как в других отраслях?

Посмотрев серию MegaStructures от National Geographic , я был удивлен, насколько быстро завершаются крупные проекты. После того, как предварительные работы (дизайн, спецификации и т. Д.) Выполнены на бумаге, сама реализация огромных проектов занимает всего несколько лет, а иногда и несколько месяцев .

Например, Airbus A380 «официально запущен 19 декабря 2000 года», а «в начале марта 2005 года» самолет уже был испытан. То же самое касается огромных нефтяных танкеров, небоскребов и т. Д.

Сравнивая это с задержками в индустрии программного обеспечения, я не могу не задаться вопросом, почему большинство ИТ-проектов настолько медленные, или, точнее, почему они не могут быть такими же быстрыми и безошибочными, в одном и том же масштабе, учитывая достаточное количество людей?

Такие проекты, как Airbus A380, представляют оба:

• Основные непредвиденные риски: хотя это не первый построенный самолет, он все же раздвигает пределы технологии, и вещи, которые хорошо работали для небольших авиалайнеров, могут не работать для более крупных из-за физических ограничений; таким же образом используются новые технологии, которые еще не использовались, потому что, например, они не были доступны в 1969 году, когда был сделан Боинг 747.

• Риски, связанные с человеческими ресурсами и управлением в целом: люди уходят в середине проекта, неспособность связаться с человеком, потому что он в отпуске, обычные человеческие ошибки и т. Д.

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

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

Тем не менее, большинство ИТ-проектов являются медленными и запоздалыми , и добавление в проект большего количества разработчиков не является решением (переход из команды из десяти разработчиков в две тысячи иногда позволит быстрее выполнить проект, иногда нет, а иногда только навредит проект и увеличить риск, не заканчивая это вообще).

Те, которые все еще поставляются, могут часто содержать много ошибок, требующих последовательных пакетов обновлений и регулярных обновлений (представьте себе «установку обновлений» на каждом Airbus A380 два раза в неделю, чтобы исправлять ошибки в исходном продукте и предотвращать сбои самолета).

Как объяснить такие различия? Это связано исключительно с тем фактом, что индустрия разработки программного обеспечения слишком молода, чтобы иметь возможность управлять тысячами людей в рамках одного проекта, чтобы очень быстро выпускать крупномасштабные, почти безошибочные продукты?

Марш Смерти Эда Тидона затрагивает несколько вопросов мета-типа.

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

• Стандартизация и разбивка рабочих элементов.

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

• Большое количество успешных, похожих проектов. A380 был не первым большим самолетом, который построил Airbus . Существует множество крупных программных приложений, но многие из них сильно пострадали в том или ином аспекте и не приблизились бы к тому, чтобы называться «успешными».

• Большое количество дизайнеров и строителей, которые работали над рядом подобных и успешных проектов. Связанный с успешной проблемой проекта, не имея человеческого таланта, который был там, сделан, что делает вещи очень трудными с точки зрения повторяемости.

• «Никогда» не создавал одно и то же дважды. Во многих отношениях самолет похож на любой другой самолет. У него есть крылья, двигатели, сиденья и т. Д. Крупные программные проекты редко повторяются. Каждое ядро ​​ОС существенно отличается. Посмотрите на различия в файловых системах. И в этом отношении, сколько действительно уникальных ОС существует? Большие в какой-то момент становятся клонами базового предмета. AIX , Solaris , HP-UX , ... глашатай обратно AT & T System V . У Windows было невероятное количество усилий в каждой итерации. Все варианты Linux обычно возвращаются к тому же ядру, что и Линус. Я говорю об этом, потому что варианты распространяются быстрее, чем действительно уникальные проприетарные ОС.

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

• QA / QC подчеркивается не так сильно, как могло бы или должно быть для крупных проектов. Это восходит к наличию более слабых интерфейсов между компонентами и отсутствию жестких спецификаций того, как компоненты должны работать. Эта разболтанность учитывает непредвиденные последствия и приводит к появлению ошибок.

• Последовательно измеримые квалификации. Обычно люди говорят о том, сколько лет они работали на языке X или в программировании. Время в используется вместо калибра или качества навыка. Как уже много раз упоминалось ранее, собеседование и поиск хороших талантов в программировании сложно. Часть проблемы заключается в том, что определение «хорошо» остается очень субъективным.

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

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

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

Итак, что мы делаем, когда планируем программное обеспечение? Ну, мы все еще проектируем, но на более ранней стадии.

В программном обеспечении нет никакой производственной линии примечания. Сборка конечного компонента (сравнительно) дешева, и тиражирование этого конечного продукта является как идеальным, так и практически бесплатным - вы копируете артефакты сборки.

Чтобы указать на некоторые цифры:

1. Изменение требований после начала реализации ; например, когда первый Airbus A380 начал создаваться на заводе, я не могу поверить, что если бы кто-то хотел еще 200 мест, их бы там разместили; но в большом программном проекте даже после того, как программисты начали разработку, можно добавить еще 5 типов пользователей.
2. Сложность - большие программные проекты чрезвычайно сложны; наверное, самые сложные проекты человеческого рода, спроектированные и разработанные;
3. Недостаточно ресурсов расходуется на этапе проектирования и архитектуры ;
4. Незрелость поля - разработка программного обеспечения - относительно молодая дисциплина по сравнению с другими сестрами-инженерами; это имеет два значения: а) не так много эвристики и хороших практик; б) не так много очень опытных специалистов;
5. Отсутствие математического доказательства - в большинстве случаев математические формальные методы не используются для доказательства того, что часть программного обеспечения работает как требуется; вместо этого используется тестирование. Это действительно в других областях техники, которые в большей степени полагаются на математику; причина этого в сложности;
6. порыв - многие менеджеры имеют недостижимые сроки; Таким образом, качество кода занимает второе место из-за крайнего срока.

Отвечая строго на вопрос - я склонен полагать, что другие имеют очень большие ожидания (особенно в отношении времени доставки) от программистов и не совсем понимают, насколько сложно программировать большое программное обеспечение.

Предпосылка вопроса немного ошибочна. И А380, и Боинг 787 были доставлены с опозданием на несколько лет.

В случае с A380 большая часть задержки была вызвана тем, что французские и немецкие подразделения Airbus использовали разные и слегка несовместимые версии CATIA. программного обеспечения для проектирования . Это несовместимо проявлялось в жгутах проводов, которые не совсем подходили для самолета.

В CATIA, которая является наиболее широко используемым программным обеспечением для проектирования самолетов, не было ничего плохого, но кто-то где-то отбросил шар конфигурации программного обеспечения.

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

И A380, и B787 должны были изменить свои конструкции крыльев после того, как у первоначального самолета были структурные проблемы.

Большие сложные проекты трудны для людей во всех областях.

Парень-небоскреб здесь. Не уверен, смогу ли я ответить на ваш вопрос, но я, безусловно, могу пролить свет на различные элементы в ветке. Здания действительно происходят очень быстро. Основным ограничением является локаль (правила). Но в целом для строительства высокого здания требуется от 3 до 10 лет.

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

Из личного опыта только один из десяти проектов когда-либо строится. Процесс основан на разработке, а не на дизайне, так что в тот момент, когда цена на сталь повышается, весь проект оказывается за окном или проектируется, так как дизайн является дешевым компонентом процесса.

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

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

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

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

В целом моя (потенциально неправильная) оценка по вопросу ОП состоит в том, что программирование - это больше искусство, чем разработка. Почему люди получают удовольствие и даже делают это бесплатно, находят выражение и элегантность в этом? Информатика также (как на олове) больше науки, чем инженерия. Почему вы пытаетесь доказать алгоритмы, а не просто соединять существующие части вместе и работать, чтобы все работало? Не уверен, имеет ли это смысл; Я не программист.

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

Тогда, как долго это делалось? Год? Два? Десять лет? Дизайн - самая сложная часть постройки чего-либо, а сама конструкция проста.

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

Сама конструкция обрабатывается автоматически компиляторами. И благодаря этому мы можем создавать целые продукты за считанные минуты.

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

Представьте себе, что в середине конструкции Airbus A380 кто-то подхватил собравшихся и сказал: «Хех, мог бы построить его как триплан?» Другие присоединились и сказали: «Да, да. Триплан. Чем больше крыльев, тем лучше». Следующие три года потрачены на то, чтобы превратить конструкцию A380 в триплан. На другой встрече кто-то говорит: «Триплан? Он старый. Нам нужен биплан. Просто снимите одно из крыльев».

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

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

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

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

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

Это потому, что эти прототипы хорошо изучены, хорошо поняты, широко используются и имеют проверенную репутацию. Не потому, что это невозможно сделать другим способом. В области ИТ стандартизация встречается редко: (крупные) проекты, как правило, заново изобретают компоненты, проводя исследования и поставку одновременно и с одними и теми же людьми!

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

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

Боюсь, что я не согласен с вашим утверждением.

Аэробус и Боинг - два примера компаний, которые строят самолеты. Сколько там компаний, которые строят самолеты? Очень мало, если вы сравните это с тем, сколько компаний создают программное обеспечение.

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

Посмотрите на машины; Есть производители высокого качества, которые производят очень долговечные и высокоразвитые автомобили (например, Land Rover, Mercedes), и есть производители, которые не будут работать в течение года без необходимости их ремонта (например, Kia или Cherry). Это прекрасный пример индустрии с чуть более низким входным барьером, где у вас начинаются слабые игроки.

Программное обеспечение ничем не отличается. У вас есть много продуктов с ошибками, с другой стороны, Windows, Office, Linux, Chrome или Google Search - это очень качественные проекты, которые были доставлены вовремя и имеют такой же уровень качества, что и самолеты.

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

Программное обеспечение тоже нуждается в этом. Если бы только люди тратили столько же времени на диагностику, профилактику или аудит состояния и качества программного обеспечения, сколько они занимаются механическими / физическими продуктами, я бы ожидал гораздо меньше подобных заявлений. Читаете ли вы журналы своего приложения каждый раз перед его запуском? Ну, если бы это был самолет, ты должен был бы ;-)

Цифровые строительные блоки могут быть 1 или 0. Между ними нет.

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

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

Я часто задавался вопросом о том же. Конечно, иногда кажется, что мы кучка любителей, которые не имеют ни малейшего представления о том, что мы делаем. Мне не нравятся объяснения, которые возлагают вину на менеджеров или другие внешние факторы - мы, разработчики, должны нести ответственность за то, что мы создаем.

Я думаю, что мы находимся в бизнесе, где ошибки дешевы . Патчирование программного обеспечения стоит дешево, по сравнению с восстановлением небоскреба или отзывом каждого проданного мобильного телефона.

Это создало культуру, где ошибки являются частью повседневной жизни . Они принимаются с пожав плечами. Хотя некоторые ошибки, вероятно, неизбежны, должны ли они доминировать в нашей повседневной работе ? Я полностью понимаю менеджеров, которые не считают, что QA стоит того, потому что они все равно ожидают ошибок. Я не понимаю программистов, которые не прилагают все усилия для создания безошибочного кода, потому что исправление ошибок скучно, как ад.

По сути, я считаю, что это проблема культуры, и я надеюсь, что она изменится.

Инженерные стандарты и практики в ИТ (как самостоятельной отрасли) сильно отличаются от аэрокосмических . Это, пожалуй, легче всего понять, если учесть, как ИТ-специалисты реагируют, сталкиваясь со стандартными документами для ИТ в аэрокосмической отрасли . Например, стандарты Joint Strike Fighter C ++ , появившиеся в последнее время в Интернете.

Многие выражают смущение или задумчивую отставку (хотелось бы, чтобы мы так поступали); и многие отвечают насмешками, утверждая, что практического способа доставки потребительских товаров таким способом не существует. Это может быть даже правильно, учитывая ожидания не потребителей, а менеджмента. Существует большое недоверие к кодировщикам, которые просто кодируют и кодируют в течение нескольких недель, ничего не демонстрируя. Боже, помоги программисту, который просто проектирует что-то в течение двух недель. Не так с самолетами.

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

Некоторые вещи от меня:

1- Стандарты и детали: это производители самолетов , а не разработчики. Я не совсем уверен, но я предполагаю, что многие детали передаются на аутсорсинг. Они не создают свои собственные электронные приборы / инструменты, они получают места в какой-то компании, двигатели, вероятно, разрабатываются в других местах и ​​т. Д.

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

2. Время выхода на рынок. Время не является критической проблемой для самолетов. Бьюсь об заклад, дизайн Airbus был завершен за несколько лет до его завершения, и они решили пренебречь любыми крупными достижениями, которые могут произойти за это время. (Так же, как и для производителей автомобилей, передовые технологии, которые они разрабатывают в настоящее время, выйдут на улицы через 5-10 лет.)

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

3- Релиз-цикл и версии. - Самолет должен быть полностью закончен, когда он «выпущен». Не существует стабильных бета-версий, ночных сборок или аналогичных. Кроме того, как только это будет сделано, его можно изменить только небольшим образом. Вы не можете добавить дополнительный уровень на 100 мест к существующему Боингу, это просто невозможно.

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

Я думаю, что ответ довольно прост:

1) Физическое построение и реализация существуют уже столько же, сколько люди - у нас были тысячи лет на разработку наших методов и техник для реализации физических проектов. «Конструкция» программного обеспечения, которая требует совершенно нового и другого набора навыков, не старше 50 лет - у нас еще не было достаточно времени, чтобы все это выяснить.

2) Виртуальное построение сложнее - вы должны «видеть» в уме то, что не имеет никакой физической реальности. Это требует от вас анализа и абстрагирования большого количества информации, прежде чем вы даже узнаете, как должен выглядеть ваш продукт, и какие шаги необходимо предпринять для его создания. Не так при строительстве моста или здания.

3) Часто гораздо сложнее найти источник программного сбоя или ошибки, чем при физической инженерии. Если балка прогибается, вы видите, где она прогибается, и вы видите опоры, которые удерживают ее и выходят из строя, и т. Д. Поиск дефекта программного обеспечения может повлечь за собой изучение большого количества кода и взаимодействующих процессов - трудных, длительных и не привязанных к законы физики и математики в том, как физические структуры.

Я попытаюсь ответить, используя дословную копию статьи из встроенной музы Джека Гэнсле. Хотя это говорит о прошивке везде, просто мысленно замените ее программным обеспечением.

По сравнению с чем?

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

Ответ: прошивка. Бесконечная стоимость, нулевая масса. Авионика теперь составляет более половины стоимости истребителя. Это кусок перемен, если учесть, что последний американский истребитель F-22 стоит прохладную треть миллиарда за штуку. Августин радостно смеется, рассказывая эту историю.

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

Рассмотрим следующий вид пузырьков, беззастенчиво снятый с Википедии и не проверенный на точность:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

Это всего лишь 110 символов без пробелов, возможно, выброшенных за час или два. Предположим, у нас не было программного обеспечения, и нам пришлось реализовать сортировку, используя какую-то другую стратегию. Сколько это будет стоить?

Инженер-механик может похвастаться тем, что его профессия строила сортировщики задолго до компьютеров. Рассмотрим сортировщик карт модели 82 IBM в 1949 году ( http://www.columbia.edu/acis/history/sorter.html ) с пропускной способностью 650 карт в минуту, что намного меньше, чем наш фрагмент кода может обойтись даже на 4 МГц Z80. Модель 82, конечно, сортировала только один столбец карты за раз; для полной сортировки колоды может потребоваться десятки проходов.

Сколько времени понадобилось, чтобы спроектировать и построить этого зверя? Годы, без сомнения. И его функциональность бледнеет по сравнению с нашим кодом, который намного быстрее и может обрабатывать гигантские наборы данных. Но это был 1949 год. Сколько времени потребуется, чтобы создать пузырьковую систему из электронных компонентов - без ПЛИС и VHDL или ЦП?

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

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

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

Все это, чтобы заменить 7 маленьких строк кода. Мало реальных встроенных программ меньше 10 000; многие превышают миллион. Сколько аппаратного и инженерного обеспечения потребовалось бы для замены реальной компьютерной программы большого размера?

Рассмотрим настоящую программу, например электронную таблицу. Сколько схем потребуется, чтобы сделать один без процессора? Это может быть размер города.

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

Так что! Программное обеспечение / прошивка имеет беспрецедентную сложность.

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

Из-за относительной молодости разработки программного обеспечения и менеджмента как дисциплины, есть некоторая дезинформация и ложь, которые все еще принимаются как факт ( см. Эту ссылку ), который препятствует разработке программного обеспечения и разработке в целом.

Не все разработчики созданы одинаково. Некоторые из них хороши, другие - нет.

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

На строительство соборов уходило до 100 лет.

Некоторому самолету Airbus требуется 1 миллион строк кода для работы.

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

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

Удивительно, но многие люди не знают, что такое бюрократия (ее часто путают с политикой), и даже если / когда у них есть проблемы с бюрократией.

Недавно мы завершили проект по внедрению аутентификации с помощью смарт-карт. Первоначально он был оценен в три месяца. Прошло 15 месяцев. Не было никаких затрат, бюджета, объема или технических причин для задержки. Область действия была довольно узкой - только для учетных записей с повышенными привилегиями (учетные записи администраторов), всего около 1200 учетных записей.

Другим важным фактором являются ваши деловые партнеры. Это будет включать в себя поставщиков. Если у ваших партнеров есть проблема, которая приводит к задержке в вашем проекте, не так много вариантов, которые фактически решат проблему задержки. Они не работают непосредственно на вас, и вы не сможете уволить этого человека в партнера, что может быть причиной. Партнер может быть уволен или может быть подвергнут финансовым штрафам или сдерживанию, но это не меняет того факта, что проект подвергся задержке. Это именно то, что произошло с Boeing, когда они применили гигантскую стратегию поставок с Boeing 787 Dreamliner .

У меня есть более короткая версия для вас:

Что бы ни было легко сделать или упростить, мы пишем программу, которая делает это вместо нас.

А затем сразитесь с мета-процессом.

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

Есть много других факторов - некоторые из них упоминаются здесь - но я хотел добавить этот момент к обсуждению.

Отсутствие ответственности ... Людям предъявляют иск, когда самолет падает. Индустрия программного обеспечения снимает с себя всякую ответственность за любые дефекты программного обеспечения, что приводит к отсутствию стимулов для создания надежного и безопасного продукта.

Большинство крупных проектов имеют высокую степень отделимости подпроектов, где вы можете определить небольшое количество проектных ограничений; весь проект будет работать, когда каждый из этих подпроектов будет завершен. Если в подпроекте что-то идет не так, все усилия не подвергаются сомнению; Вы просто ищете альтернативные способы завершения подпроекта (например, используйте другой движок).

Это возможно, но сложно, как практически, так и с точки зрения человеческой природы, в программных проектах.

Частично, другие отрасли промышленности твердо поняли, что такого рода отделимость - хорошая вещь. Например, если вы собираетесь использовать авиационные двигатели Rolls Royce, вам не нужно использовать специальные болты Rolls Royce и точки крепления, которые работают только с крыльями определенной конструкции, а затем, если вы попытаетесь переключиться на Pratt и Whitney, Вы должны перепроектировать все свое крыло с нуля (что, в свою очередь, требует полной реконструкции фюзеляжа, что, в свою очередь, требует от вас покупки разных сидений, что, в свою очередь, требует покупки другой развлекательной системы в полете, который...). Может быть несколько связей - вы не можете просто поменять движки без заботы - но большие проекты обычно работают лучше, когда такие вещи минимизированы.

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

Создание программных систем очень отличается от построения физических структур. То есть реализация очень сильно отличается. Например, при строительстве огромного танкера вы выполняете множество относительно простых (хотя и не простых!) Задач, таких как сварка деталей роботом или рукой, затягивание всех гаек и болтов, покраска, выполнение отделки путем переноса всех оборудование и мебель и тому подобное. На самом деле все это очень просто .

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

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

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

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

Определение «большой проект» искажено.

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

• Клон Pac-Man.
• Калькулятор
• Текстовый редактор

Я уверен, что вы думаете ... "но это небольшие проекты! Текстовый редактор прост ". Я бы не согласился с вами. Компьютеры невероятно сложны. Иногда установка и настройка пользователей в операционной системе может быть сложной, и вы даже не писали ОС и не собирали аппаратное обеспечение.

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

Я думаю, что проблема заключается в ожидании. То, что технология существует, не означает, что ее использование будет успешным (или разумным) на некоторое время. Если бы другие отрасли вели себя так же, как и индустрия программного обеспечения, к концу десятилетия у нас были бы пылесосы с питанием от черной дыры. Или какой-нибудь «провидец» будет располагать ресурсами для строительства базы на Луне и решит, что Starbucks действительно «закруглит» впечатления для посетителей. Я не думаю, что проблема в индустрии программного обеспечения, но ожидания возлагаются на нее.

Хотя это едва ли единственная вещь, которую можно упомянуть, я думаю, стоит отметить одну основную вещь. Большинство продуктов предназначены для соответствия существующему поведению. Даже продукт, который является радикальным прорывом (например, автомобиль), обычно создается так, чтобы соответствовать существующему поведению, и просто сделать его немного проще / проще / дешевле / чем угодно, чтобы сделать это. Да, часто есть некоторое побочное влияние на существующее поведение (например, получение топлива для автомобиля вместо еды для лошадей), но большинство последних имеет тенденцию быть довольно незначительным побочным эффектом.

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

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

Airbus A380 не был успешным проектом, как вы упомянули. Мне довелось работать в компании CAD / CAM, и мне сказали, что это (у нас был и проект Airbus) было отложено на несколько лет, потому что они использовали разные версии программного обеспечения в другой компании. То есть разные части проектировались в разных частях света. И во время интеграции они узнали, что весь дизайн не может быть интегрирован, поэтому они должны перепроектировать его в одну версию. Поэтому, глядя на это, я не думаю, что это было успешно. Если бы это произошло 2-3 года назад, это стало бы переломным моментом для Airbus.

Что касается надежного программного обеспечения, вы смотрите на любой самолет, автомобиль (ABS, EPS, климат-контроль и т. Д.) Или космический челнок, на котором установлено более 50% программного обеспечения, и я считаю, что они очень надежные. Просто мы ближе к программному обеспечению, и программ гораздо больше, поэтому мы видим в них больше ошибок.

Посетите: http://www.globalprojectstrategy.com/lessons/case.php?id=23 и посмотрите, насколько успешным был Airbus A380.

Здесь инженер-программист с инженерным образованием и жена, которая работает на стройке. У нас были долгие дискуссии (и споры) о различиях нашей работы.

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

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

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

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

Вспомните, насколько полностью изменились стандарты: от сборки до C, C ++, Java, JavaScript, C #, PHP и т. Д. Там не так много кода, который может быть переработан 10 или 20 лет назад. Это совсем другое ... автомобильная или авиационная промышленность, когда вы можете продолжать совершенствовать дизайн десятилетиями назад.

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

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

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

У вас есть методы программирования, в которых используется обширное тестирование, например экстремальное программирование (которое фактически использовалось в программных мегапроектах). Но из-за сжатых сроков (которые могут быть специально сокращены) заманчиво пропустить все это программирование и запустить с ошибками. Стиль Джоэла Спольски «всегда исправлять все ошибки» в конечном итоге сэкономит больше времени, но недисциплинированный пропустит это и потерпит неудачу.

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

Я видел ИТ-проекты на миллион долларов, над которыми работало менее 10 человек. Больше людей замедлило бы проект и добавило бы ненужную бюрократию. WhatsApp является примером «маленького» проекта, который стоит миллиарды долларов. Это не значит, что крупные проекты невозможны, но вам просто не нужны тысячи людей для производства программного обеспечения на миллиарды долларов.

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

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

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

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

Для меня главная проблема, с которой сталкиваются разработчики программного обеспечения - это варианты использования, пользовательские и кроссплатформенные.

Сценарии использования

Сколько вариантов использования у самолета? Большинство из них просто летать из одного места в другое. Может быть, есть еще такие, как радар, управление движением и т. Д., Но сценарий использования понятен и не очень. В разработке программного обеспечения мы сталкиваемся с неясными требованиями и пользователями, которые не знают, чего хотят. Разному пользователю нужна другая конфигурация / поток, может ли самолет быть настроен по желанию пользователя (я хочу иметь телевизор и холодильник!)?

пользователь

Кто управляет самолетом? Пилот, второй пилот, некоторые стюарды (если считать) и операторы вышек. Все они профессионалы, и их должностные инструкции ясны. Программное обеспечение используется нубами и манекенами, не говоря уже о злых хакерах и взломщиках, хотя все еще должно быть интегрируемым с другими модулями (такими как OpenID или Google AdSense ). Если самолет может эксплуатироваться манекенами, оставаясь при этом живым от ракет или грабителей-ниндзя, то вы можете сказать, что самолет имеет то же качество с программным обеспечением.

Кроссовые платформы

Самолет летит только в небе земли. Я не уверен, как они справляются с туманным или ветреным или жарким, холодным и влажным климатом, но самолет не рассчитан на полет с разным уровнем гравитации (я буду удивлен, если он сможет летать на Марс ). Иногда приложение должно работать на разных платформах, таких как Internet Explorer, Google Chrome , Firefox и Safari для браузера (извините, Opera ), или Windows XP / 7/8, или Linux для уровня ОС. Не говоря уже о мобильных устройствах и разном разрешении и ориентации.

Если вы считаете, что в других отраслях проекты завершаются без инцидентов, вам следует прочитать историю о здании Центра Citigroup, построенном в 1977 году. Даже после почти 7 лет планирования и строительства здание было завершено с серьезным недостатком дизайна, который мог привести к обрушению из-за штормовые события ожидаются каждые 16 лет.

Другими словами, на каждый год существования Citicorp Center был шанс 1 к 16, что он рухнет.

Оригинальные дизайнеры не знали о проблемах, но, к счастью, их поймал студент, изучающий здание.

все казалось просто отлично - пока, как говорит ЛеМессюриер, ему не позвонили. Согласно LeMessurier, в 1978 году студент-архитектор связался с ним со смелым заявлением о строительстве LeMessurier: центр Citicorp может взорваться от ветра.

Ремонт был сделан буквально под покровом ночи, вовлекая наименьшее количество людей, чтобы сохранить тайну недостатка дизайна.

План аварийной эвакуации был подготовлен для радиуса в 10 блоков, окружающего здание.

Они сваривали всю ночь и уходили на рассвете, когда жители здания возвращались на работу.

История оставалась в секрете, пока писатель Джо Моргенштерн не услышал, как ее рассказывают на вечеринке, и не взял интервью у Ле Мессюриер. Моргенштерн сломал историю в Нью-Йорке в 1995 году.

Что поднимает вопрос; сколько других роковых недостатков дизайна в проектах было тайно исправлено или проигнорировано без публичного признания.

• Недостаток дизайна, который почти уничтожил небоскреб Нью-Йорка (slate.com)
• Центр Ситигруп (wikipedia.com)