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


509

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

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

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


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

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

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

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

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

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

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

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


127
Интересный вопрос. Я испытываю желание сказать, что качество среднего работника в индустрии программного обеспечения менее квалифицированное и квалифицированное, чем, скажем, гражданское строительство, где каждый инженер прошел строгую и интенсивную степень и, вероятно, тоже получил свой устав. Кроме того, сложность большого программного обеспечения (например, ОС, MS Office), вероятно, намного больше, чем у самолета. Конечно, еще много мест для провала! И последний важный момент: большинство программ более или менее работают, даже если они написаны плохо и содержат много ошибок ... конечно, стоимость отказа обычно намного меньше, чем у самолета!
Нолдорин

155
Найдите человека, который на самом деле работает в любой из этих отраслей (но не в сфере PR), и спросите его о «крупных безупречных проектах». Я могу практически гарантировать, что вы заработаете мучительный смех.
Майкл Боргвардт

151
Реализация программного проекта занимает секунды или минуты; это то, что происходит, когда вы нажимаете «compile» в вашей IDE. С другой стороны, программирование - это дизайн . Сколько времени ушло на разработку A380?
Муравей

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

117
«Представьте себе« установку обновлений »на каждом Airbus A380 дважды в неделю ...» Представьте, что вражеские роботы постоянно проверяют самолет на наличие уязвимостей, в то время как неподготовленные пилоты случайным образом нажимают на кнопки. Могу поспорить, вам понадобятся регулярные патчи.
Натан Лонг

Ответы:


337

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

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

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

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

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

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

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

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

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

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


23
Было трудно выбрать ответ, чтобы принять один из нескольких очень хороших ответов, но я, наконец, выбрал этот, несмотря на то, что у него нет самых высоких голосов. Фактически, как этот ответ, так и ответ m3th0dman, объясняют, почему именно такая специфика в ИТ-индустрии помогает понять, что делать в будущем, чтобы сократить разрыв. По сравнению с ответом m3th0dman этот кажется гораздо более подробным.
Арсений Мурзенко

3
+1, но я мог бы просто добавить, что поскольку программное обеспечение существует в сфере разума, оно имеет почти бесконечные возможности, в то время как каждый построенный план должен соответствовать конечным требованиям реальности.
Спенсер Рэтбун

5
Очень хорошо ответил. В качестве интересного примера - представьте, был ли большой самолет спроектирован и реализован группой людей, не имеющих процесса или истории компании, - людей, которые просто собрались и создали бизнес, чтобы построить самолет в масштабе 747 с нуля. Вот так 90% программных проектов, которые я видел, выполнены. Остальные 10% с опытными архитекторами и компаниями с историей и процессами кажутся более успешными. В качестве контр-примера рассмотрим процесс разработки программного обеспечения, которое заставляет людей умирать, когда оно выходит из строя.
Билл К

7
Я думаю, что вы приняли неправильный ответ. Дэнни Вудс был прав: неудачи в других отраслях встречаются так же часто, а программирование не строит дизайн. Конструкция в мире программного обеспечения выполняется компилятором и является практически бесплатной. Ваш первоначальный вопрос был очень красноречивым. После того, как предварительная работа (проектирование, спецификации и т. Д.) Выполнена на бумаге, работа по проектированию и спецификации физической структуры становится ТОЧНОЙ спецификацией того, как построить структуру. Единственное, что соответствует этому в мире программного обеспечения - это код. Кодекс дизайн, компиляция строительная.
Майкл Браун

5
Но сам вопрос некорректен. Пока нам нужно критически взглянуть на свои недостатки. Действовать так, как будто индустрия программного обеспечения является единственным, у которого есть неудачные проекты, смешно. Сказать «как только все было сделано» - это тоже сказочно. Даже если вы не согласны с тем, что программирование - это проектная деятельность, как часто вы видите детальный, железный дизайн, заранее разработанный для программного обеспечения? Люди дают нечеткие спецификации на программное обеспечение, потому что они ожидают, что смогут изменить программное обеспечение, если спецификации будут неправильными, не заботясь о том, как эти изменения могут повлиять на все решение.
Майкл Браун

452

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

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

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

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


47
Даже в отрасли, о которой говорилось в OP, Aerospace, Boeing 787 Dreamliner и JSF F-35 имели значительные задержки. На прошлой неделе обрушилась автостоянка в одном из крупных торговых центров в Сиднее. У Сиднея очень строгие строительные нормы, но случаются ошибки.
TeamBob

23
Тысячу раз это. Даже ссылка на график вопроса показывает, что проект фактически разрабатывался с 1988 года.
Исходным

2
Многие крупные проекты, такие как F-35, телескоп Хаббл и т. Д., Опоздали из-за программной стороны разработки. Хаббл фактически годами хранился в хранилище, потому что программное обеспечение не было готово.
MrLane

11
@MrLane: в реальном мире это работает так. Расписание устанавливается, когда предполагается, что аппаратное обеспечение должно быть выполнено, а программное обеспечение должно быть выполнено. Разработчики оборудования предоставляют ICD команде разработчиков программного обеспечения, поэтому команда разработчиков программного обеспечения может писать свой код без оборудования. Аппаратное обеспечение значительно сокращает график и меняет свои интерфейсы, чтобы обойти проблемы hw, часто без уведомления команды sw. Наконец, HW работает и опаздывает. Конечно, SW не работает из-за множества неожиданных hw «функций». Потому что дешевле исправить проблемы с оборудованием в ...
Dunk

11
В настоящее время команда разработчиков программного обеспечения должна внести изменения в ICD и найти обходные пути для неисправного оборудования. Таким образом, в дополнение к тому, что hw доставляется с опозданием, и теперь команда sw также исправляет аппаратное обеспечение с ошибками, кого обвиняют в опоздании? Ну, команда разработчиков еще не закончила. Это программное обеспечение, которое опаздывает. Все всегда забывают об ошибках в графике работы электрооборудования, механики и системотехники, которые зависели от sw, а затем вынуждали их переписывать и предъявлять дополнительные требования. Все, что они видят, это то, что команда sw все еще занимается кодированием. Таким образом, программное обеспечение опаздывает.
Данк

180

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

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

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


55
Формальное математическое доказательство в программном обеспечении, помимо того факта, что зачастую это практически невозможно сделать правильно, в конечном итоге является не чем иным, как написанием программы дважды (один раз на реальном языке программирования и один раз на языке спецификации формального доказательства) и проверкой того, что оба версии делают точно так же.
tdammers

5
tdammers, есть инструменты, которые могут помочь вам написать оба одновременно: Coq поддерживает «извлечение программы» для извлечения программы в OCaml или Scheme из сертифицированной программы Coq.
JKF

66
«Изменение требований после начала реализации». Я называю это «проблемой перемещения туалета». Вы строите дом, наносите последние штрихи на ванную, а владелец хочет, чтобы туалет находился в другом месте. Вы даете им смету. Они возражают, говоря: «Почему так сильно, я просто хочу в туалет на расстоянии 8 футов?». Затем вы объясняете, что вам нужно установить новую сантехнику, вскрыть стены / полы и т. Д., Чтобы иметь возможность перейти в туалет. Поздние изменения всегда дороги.
Ленивый DBA

7
Я бы сказал, что тестирование самолета на самом деле намного сложнее, чем тестирование программного обеспечения. С самолетом вся математическая магия, которую вы сотворили, оказывается бесполезной, когда вы полагаете, что программный симулятор или созданные вами ветряные турбины на самом деле не отражают то, как все работает, когда вы там. Формальное доказательство в программном обеспечении - только трудная проблема, по сравнению с формальным доказательством в разработке, которое невозможно.
Ли Райан

2
# 1 в вашем списке - самая важная IMO, я бы добавил к ней еще две вещи: -Множество больших изменений может быть сделано за короткий промежуток времени (например, «давайте переключим протокол связи!»), Которые не сломают материал в краткосрочной перспективе, но многие из них затрудняют управление проектом в долгосрочной перспективе. - Изменения в среде, в которой работает программное обеспечение, могут резко измениться за короткое время. В то время как основные условия для самолета останутся прежними (должны летать в штормах, должны приземляться на твердых взлетно-посадочных полосах ...), программное обеспечение может полностью сломаться, если, например, выйдет новая версия ОС.
sydd

140

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

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

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

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

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

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


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

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

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

6
И учитывая, что у A380 был большой отзыв еще в 2010 году, я бы даже не назвал его «безупречным».
Мухаммед Алкарури

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

112

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

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

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

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

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

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

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

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

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


2
+1 Спасибо за понимание. «проектировать, если вы знаете, как все работает» -> «проектировать, если вы не знаете, как все работает»?
Tokland

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

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

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

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

44

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

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

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

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


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

22
@NathanLong: Особенно, если они выпускали новые формы бетона каждые три года, и кто-то придумал, как можно запустить несколько лифтов за один вал, и вдруг сталь перестала быть крутой, и все решили построить свои каркасы из углерода волокна. Подобные вещи постоянно происходят в индустрии программного обеспечения.
TMN

2
«Разработка программного обеспечения - это в основном процесс проектирования, где проектная документация - это сам исходный код», - вы только что открыли мне глаза. Благодарю.
Брат Кевин Д.

@ TMN Представьте себе, если бы при строительстве небоскреба они меняли цветовую палитру интерьера, потому что она не выглядит правильно. Это относится к любому компоненту здания. Попытка запустить несколько лифтов на одном валу - это одно, но вам нужно будет протестировать 20 лифтов от разных поставщиков, прежде чем даже пытаться подключить все их к валу ...
Loïc Faure-Lacroix

@ LoïcFaure-Lacroix: инженеры могли бы протестировать 20 различных лифтов, разработчики просто использовали бы тот, который описан в блоге, где они впервые услышали об этом. Затем, когда здание открылось и возникла проблема с лифтами, они обнаружили, что компании, которая их построила, больше не существует. Когда они попытались получить замену от другого поставщика, они обнаружили, что их оригинальные лифты использовали нестандартный вал ...
TMN

39

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

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

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


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

3
Это приходит на ум: youtube.com/watch?v=BKorP55Aqvg&feature=kp
miraculixx

21

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

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

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

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

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

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


5
+1. Хороший пример для стандартизации (стандартный лист простого болта). В ИТ редко встречаются нормализованные компоненты. Возьмите регистрационные формы: каждый веб-сайт заново изобретает свои собственные, и лишь немногие разработчики знают, как их регистрационная форма ведет себя с юникодом, с пустыми строками, со слишком длинными строками и т. Д.
Арсений Мурзенко,

1
@MainMa: плохой пример, вы создаете свои кнопки, текстовые поля, поля параметров, поля параметров из divs? Нет, вы повторно используете элементы формы браузера; и браузеры использовали элементы формы операционной системы.
Ли Райан

4
Я скорее говорил о внутренних органах, а не о контроле. Возьми какой-нибудь случайный сайт. Можете ли вы использовать китайские символы для пароля? Можете ли вы использовать 25-символьные пароли? Что произойдет, если вы введете пробел в пароль или имя пользователя? Все это можно нормализовать, но это не так, и каждый человек заново изобретает колесо для каждого проекта, часто плохо, то есть без хеширования и / или засолки, или паролей, ограниченных шестнадцатью символами (пример: MSN), и т. Д.
Арсений Мурзенко,

4
Смена ИТ с «ремесленников» на «фабрики» может оказаться невозможной. Фабрики выполняют процесс, который уже был создан. Рабочие на фабрике выполняют свой процесс практически без человеческих мыслей. Из-за этого многие фабрики заменили людей роботами. В программном обеспечении вы не выполняете процесс, а создаете его. Создание программного обеспечения было бы больше похоже на проектирование фабрики и ее процессов, чем на управление фабрикой. Хотя создание программного обеспечения может выиграть от стандартов, оно не может в принципе стать фабрикой.
mike30

@ArseniMourzenko - это плохое сравнение, если сравнивать «технические паспорта для болтов» (т.е. инструменты, оборудование) с «стандартами регистрационных форм». Регистрационные формы были бы больше похожи на «крышу» или «входную дверь» (на самом деле, существует множество способов сделать это). То, с чем сравнивается болт, больше похоже на поведение конвейера процессора. Это далеко не то, что нам нужно: надежная ОС (со строго определенными характеристиками, а не «данные могут попасть на диск в зависимости от используемых опций монтирования») и инструменты разработки Ditto (они должны иметь возможность проверять 90% кода на стандартность свойства)
sehe

15

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

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

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

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

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

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

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


5
Windows часто не доставлялась вовремя (Longhorn, она же Windows Vista, первоначально должна была появиться в 2003 году). Я не знаю о Office, но большинство других программных проектов, о которых вы прямо упомянули, не имеют сроков, или их график выпуска настолько част, что они включают в себя все функции, готовые к выпуску, и отталкивают все остальное, пока он не будет готов ,
Кен Блум

2
Это лучший пример высококачественного программного обеспечения: 420 000 строк и без ошибок: программное обеспечение для космического челнока . Имейте в виду, что получение такого качества сопряжено с огромными затратами.
dodgy_coder

@dodgy_coder, Создание безопасного самолета тоже не дешево ;-)
Карим Ага

1
@PaulNathan приличный очень субъективен;)
Джеймс Хури

3
@KarimA .: Создание безопасного самолета не дешево, но большая часть того, что делает самолет безопасным, это программное обеспечение ... Так что важной частью дизайна самолета на самом деле является разработка программного обеспечения!
благоговение

10

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

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

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


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

9

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

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

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

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


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

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

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

7

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

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

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


5

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

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

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

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

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

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

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


5

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

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

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

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


4

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

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

Прошивка самая дорогая вещь во вселенной. В своей замечательной книге «Законы Августина» Норман Августин, бывший генеральный директор 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; многие превышают миллион. Сколько аппаратного и инженерного обеспечения потребовалось бы для замены реальной компьютерной программы большого размера?

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

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

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


3

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

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


3
+1 на незрелость разработки ПО. У гражданского строительства было несколько тысяч лет, чтобы развить свои методы. Аэрокосмическая была сотня, и основана на других инженерных дисциплинах. Программное обеспечение еще молодо. Это также обычно плохо понято. Люди могут строить мосты через ручьи или делать бумажные самолетики в детстве - на самом деле это не так для программного обеспечения.
Энди Бернс

3

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

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


3

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

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

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


Кельнский собор был основан в 1248 году, а закончен в 1880 году. 632 года.
gnasher729

3

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

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

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

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


3

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

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

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

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

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


Я согласен. Большие программы могут быть доставлены безупречно и в срок, потому что они были выполнены сто раз за 3 десятилетия. Например, текстовый редактор.
Дрооганс

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

3

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


1
Я говорил это в течение долгого времени. Если вам предъявят иск в случае сбоя вашего приложения, код будет намного более надежным ... И есть много компаний, которые я бы хотел подать в суд - например, MS: сколько часов потеряно из-за всех их обновлений, исправлений и ошибки и исправления, которые ломают другие вещи. Подайте в суд на тех, кто потерял часы, и качество повысится БЫСТРО.
Вектор

Если бы это было так, стоимость увеличилась бы, а функции снизились бы.
Джим Г.

1
@JimG. Речь шла о надежности, а не о характеристиках и ценах. Конечно, необходимость сделать более надежный продукт будет вводить больше ограничений в пространство вашего дизайна, и могут пострадать другие аспекты (особенности и стоимость).
GreyGeek

4
А стоимость Boeing 737 составляет 50-80 миллионов долларов. Вы платите каждый раз, когда получаете один - вы платите каждый раз, когда открываете Office? Если бы мне платили каждый раз, когда кто-то использовал мое программное обеспечение, черт побери, я был бы предан надежности.
FlavorScape

1
@Jim G: Я бы предпочел иметь 1 стабильную версию продукта, а не 5 дрянных.
Джорджио

2

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

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

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

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


2

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

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

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

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

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


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

1

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

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

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

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

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

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


Черная дыра работает пылесосы? Как насчет функциональной безопасности?
Питер Мортенсен

Недостаток функциональной безопасности? Это особенность! Мы выступаем за использование неизменных конструкций при попытке очистить что-либо с помощью пылесоса с черной дырой.
Дрооганс

1

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

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

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


1

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

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

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


1

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

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

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

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

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

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

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

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

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

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

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

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


0

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

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

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

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


Я не понимаю вашу точку зрения. Во-первых, многие языки довольно старые. Яве более двадцати лет. Python почти тридцать лет. Да, есть новые языки, но мы не отказываемся от языка, чтобы переходить на новый язык каждые два года. Хотя принятие новой среды, IDE или язык может быть фактором медлительности для команды, я не нахожу тех, которые используют знакомые инструменты особенно быстро. А авиастроение? У самолетов типа Boeing 787 есть много новых вещей, которые сложно реализовать.
Арсений Мурзенко

@ArseniMourzenko Что ж, Java была популярна для программирования веб- клиента после его появления и для построения графического интерфейса, когда появились колебания, но оба увлечения длились всего несколько лет. Черт возьми, до 1990-х годов не было WWW. Веб-программирование - это то, где самолеты были в 1910 году или около того. Но этот темп продолжается.
Питер А. Шнайдер

-1

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

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

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

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

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

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

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


-1

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

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

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

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

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

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.