Почему программное обеспечение не так надежно, как автомобиль? [закрыто]

У меня был пользователь задать мне этот вопрос. Мы знаем, что машины ломаются, но это из-за чего-то физического (если не задействовано программное обеспечение!).

Я пытался ответить, что программное обеспечение является гораздо более молодой отраслью, но пользователь возразил: «Разве автомобильная промышленность не стала намного более стабильной и надежной с меньшим количеством людей?».

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

Итак, почему программное обеспечение не так надежно, как автомобиль?

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

Я разрабатываю программное обеспечение и механические части.

Это сложность.

Потому что в современном программном обеспечении есть миллионы «частей».

Программные части очень сложны и имеют много СОСТОЯНИЯ. Механическая неподвижная часть не имеет состояния.

Механическая движущаяся часть имеет свою позицию (одна переменная).

Программа, которая работает и использует 1 МБ ОЗУ, имеет миллион байтов состояния. Это гораздо больше состояния, чем любая нормальная механическая система.

Будет комбинация состояний, которые никогда не будут проверены, потому что они случаются так редко. В механической системе (например, в автомобиле) легко проверить, что механические детали не ударяются друг о друга во время работы. Механическое программное обеспечение САПР, которое я использую на работе, делает это автоматически.

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

Даже «Hello World» работает на операционной системе. Старые 8-битные системы и миникомпьютерные операционные системы были довольно надежными, потому что они были просты.

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

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

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

Это вопрос потребительского выбора.

Если бы потребители требовали, чтобы программное обеспечение было таким же надежным, как моя Honda Civic (в отличие от моего старого Ford Maverick), это было бы так. Некоторые организации требуют надежного программного обеспечения и получают его, как правило, для встроенного программного обеспечения, иногда для критически важных для безопасности вещей, таких как космические полеты и управление воздушным движением. Программное обеспечение до сих пор не идеально, но не автомобили.

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

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

Если бы только компьютер (и соответствующее программное обеспечение) было так просто.

У компьютера какой гигабайт памяти? Миллиарды шлепанцев? Терабайт диска? Триллионы "движущихся" частей?

Программное обеспечение может иметь 10 тысяч или 100 тысяч отдельных строк кода. Плюс это много (или больше) в юнит-тестах и ​​инструментах.

Нет, аргумент "машины тоже сложны" - это чушь. Программное обеспечение намного, намного, намного сложнее, чем автомобиль.

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

Сравните это с разработкой программного обеспечения.

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

Короче говоря, существует ряд причин, по которым автомобиль будет восприниматься как «более надежный», чем программное обеспечение. Я только что придумал пару.

Авто надежны. Так же самое программное обеспечение.

Но ... нестандартные автомобили и нестандартное программное обеспечение имеют свои проблемы.

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

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

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

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

Кроме того, это одна из главных причин того, что применение традиционных методов проектирования к разработке программного обеспечения является катастрофой.

1. Производители автомобилей получают всю спецификацию до того, как они произведут «конечный» продукт.
2. Автомобильные пользователи не склонны делать глупости, которые дизайнеры не ожидали.
3. Автомобили «обновляются» только один раз в год (как правило), в то время как ожидается, что большинство программного обеспечения будет обновляться много раз в год.

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

Там на самом деле очень простая причина.

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

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

Мне нравится большинство ответов до сих пор. Вот мое вращение на этом.

Стоимость отказа более серьезна для автомобилей, чем для программного обеспечения.

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

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

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

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

Мне нравится думать об автомобиле как о приложении. Пока ОС - это дорога, по которой работает приложение.

Интерфейс между дорогой и автомобилем хорошо определен. Хорошо протестирован и тщательно проверен на обратную совместимость (что легко, поскольку интерфейс прост). Но даже при этом у вас есть некоторые проблемы с обратной совместимостью. Автомобили типа "Фарри" с трудом бегают по дорогам типа "грязные дороги".

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

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

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

Когда вы начинаете ограничивать возможности пользователя изменять ОС, надежность приложений может стать почти безупречной. Посмотрите на все эти встроенные устройства. Мы не позволяем пользователям около их ОС и вашей работы нормально и непрерывно 24/7 без перерыва.

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

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

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

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

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

1. Недостаток обмена информацией (программисты летают в одиночку или в небольших группах - дизайнеры автомобилей работают с взаимосвязанными командами внутри большой корпорации, и все они делятся своими знаниями; если бы мы все работали в крупных корпорациях, мы все были бы лучшими программистами благодаря обучению от других, именно поэтому такие вещи, как программы с открытым исходным кодом и онлайн-ресурсы очень важны)
2. Ожидания абитуриентов (это нормально, если автомобильный дизайнер только незначительно пригодится в течение первых 5-10 лет, но если программист пойдет на собеседование и скажет, что он / она будет бесполезен в течение 5-10 лет, интервью окончено)
3. Недостаточное тестирование на проникновение (из-за нехватки средств, проблем с законностью и т. Д .; автомобильные производители, однако, швыряют машину за машиной в кирпичную стену, имеют аэродинамические трубы, имеют относительно простые требования к производительности и т. Д.)
4. Прозрачность информации (вы не знаете, как работает большинство программ; вы предполагаете или делаете предположения, основываясь на интервью, пресс-релизах, рекламе и т. Д .; на автомобилях, однако, большинство материалов именно для вас)
5. Врожденная инкапсуляция знаний (парень / робот, сваривающий раму вместе, не должен знать математику системы контроля устойчивости; программисты должны быть осведомлены о тысячах или десятках тысяч вещей, неизвестных среднему человеку, тогда как только автомобильные дизайнеры надо знать сотни или тысячи)
6. Осязаемость (помогает, когда видишь)
7. Age of Field (дизайн автомобиля тысячи лет; автомобилю более 250 лет [паровые двигатели и т. Д.])
8. Критичность подсистем (автомобили по-прежнему будут «работать», даже если многие их части перестанут работать - электрические замки, электрические стеклоподъемники, ОВК, стеклоочистители, разбитые окна, потерянные колпаки, спущенные шины [надеть новое], радио, свет или два, удаленный вход и т. д .; когда что-то на компьютере выходит из строя, это часто сценарий SHTF)
9. Взаимозависимость (когда один компьютер ломается, нередко он затрагивает сотни или тысячи других компьютеров; когда один автомобиль ломается, это довольно редко, когда другие автомобили затрагиваются - если другие автомобили затрагиваются, это почти всегда только 1 -3)
10. Общее обвинение (если одна часть компьютера или один компьютер из тысячи выходит из строя и причиняет вред системе, вина распространяется на весь компьютер или, в последнем случае, на всю сеть компьютеров; если ваш автомобиль поражен автомобилем с неисправные тормоза, или если автомобиль глохнет и не запускается на шоссе, виновата только отдельная часть автомобиля)
11. Системы Finite vs. Infinite (в автомобили может быть упаковано столько всего, и от них ожидается, что они будут работать только в ограниченных условиях - например, вы не водите BMW по пересеченной местности, что может делать только джип-подобный автомобиль; с компьютерами, однако возможности де-факто бесконечны - все время появляются новые вещи, новые API, новые ОС, новые дыры в безопасности, iPad, программное обеспечение для мобильных телефонов, новое, новое и т. д.)
12. Объем необходимого объема знаний (человек с 130-140 IQ может выучить почти все, что нужно знать об автомобилях, но может узнать лишь часть того, что нужно знать о компьютерах и программировании)

Простая причина, почему вся логика имеет недостатки:

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

Программное обеспечение, с другой стороны, имеет Input -> Process -> Output . Из-за этой природы система не может быть полностью предсказана или понята.

Дональд Рамсфелд сказал это лучше всего:

«Есть известные известные люди; Есть вещи, которые мы знаем, мы знаем. Мы также знаем, что есть известные неизвестные; то есть мы знаем, что есть некоторые вещи, которые мы не знаем. Но есть и неизвестные неизвестные - те, которых мы не знаем, мы не знаем. ”- министр обороны США Дональд Рамсфелд

В итоге:

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

Это глупый вопрос (не от вас, а от оригинального человека).

Это звучит как мой отец (механик), который ненавидит компьютеры, но проводит весь день на eBay.

Это все равно, что спросить: «Почему дерево надежнее моли?».

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

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

Мой Commodore 64 (26 лет) работает отлично и не ремонтировался. У обоих моих автомобилей (менее 10 лет) был очень капитальный ремонт. Покажите мне автомобиль с тысячами и тысячами часов использования, которому 26 лет, и который до сих пор работает на 100% так же, как и на заводе.

Программное обеспечение основано на битах: 0 и 1. Автомобили основаны (главным образом) на механических деталях.

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

Программное обеспечение, по большей части, не имеет такой вещи, как постепенный отказ. Это либо работает, либо ломается. Деление на ноль не является «почти правильным»; это просто ошибка. Когда вы пытаетесь сохранить на диск без достаточного места, вы не можете сильно сжать, чтобы заставить все данные в; это просто не пойдет.

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

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

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

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

Автомобили на самом деле не так надежны, как вы думаете. Просто ошибки могут оставаться скрытыми в течение длительного времени (или игнорироваться), не вызывая сбоев. В вашей машине течет масло и / или охлаждающая жидкость? Нет? Ты уверен? Вы, вероятно, не правы ... Это, вероятно, просто утечка небольшого количества где-то, что вы еще не заметили ... Теперь распространите это на подвеску, панели кузова, салон и т. Д. Я не думаю, что когда-либо все же столкнулся с машиной, с которой я не смог найти что-то не так. Тем не менее, подавляющее большинство частей являются лишними для миссии транспорта. Не так с компьютером. Почти каждая часть в компьютере имеет решающее значение.

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

Во-первых, конечно, некоторые SW абсолютно надежны, и автомобили - особенно британские и итальянские - не обязательно настолько надежны.

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

• Гарантийные расходы. Когда ваш SW не удается, вы перезапустите его. Возможно, вы отправите отчет об ошибке. Или используйте дорогостоящий контракт на поддержку. Когда ваша машина выходит из строя, вы ее привезете и потребует, чтобы на нее было по гарантии. Это будет стоить создателю $ 100 и выше. Если бы каждый сбой SW стоил производителю 2 доллара, я вполне уверен, что SW будет более надежным.

• JD Powers (и другие рейтинги качества). JD Powers опрашивает ThingsGoneWrong (это может быть что угодно). И если этот рейтинг действительно плохой, люди просто не будут покупать вашу машину, по крайней мере, не за деньги, достаточные для получения прибыли. Если бы у нас была JD Powers для sw, и люди действительно заботились об этом, я уверен, что sw будет более надежным.

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

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

Хотя существуют и другие правовые последствия для программного обеспечения, важно отметить, что если программное обеспечение дает сбой каждый раз, когда вы нажимаете кнопку «Сохранить», то это просто вопрос исправления / исправления, и вы продолжаете. Если при каждом включении индикатора происходит авария автомобиля, то это гораздо хуже . Для Microsoft Outlook просто не так важно запускаться без неожиданного сбоя, как для внедорожника, который запускается без неожиданного сбоя.

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

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

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

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

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

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

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

1. Абстракция, занимающаяся программным обеспечением. Это приводит к тому, что создатели программного обеспечения неправильно понимают, как все действительно работает. Со временем все больше и больше абстракций добавляется. Например, язык ассемблера дает вам прямое управление машиной. С более отвлеченный, но все же близко к машине. Java, C # и то, что будет дальше, сильно абстрагируют то, что происходит в машине. Другой пример: если вы программист, который хочет понять, как работает сеть на уровне программного обеспечения, то вы должны знать, что нужно программировать на C, потому что инфраструктура (как программное обеспечение) написана на C.

2. Различный опытЗнание создателей приводит к разным результатам. Разные разработчики создают программное обеспечение с разной надежностью. То же самое можно сказать и о автопроизводителях. Однако разница в том, что любой, кто может использовать редактор и компилятор или даже просто установить IDE (интегрированную среду разработки), может создавать программное обеспечение бесплатно. Чтобы сделать машину, вам нужны огромные инвестиции, фабрика (некоторые могут сделать машину, не используя ее, но вы не найдете ее повсюду). Тот факт, что вы вложите огромные инвестиции, означает, что вы попытаетесь нанять лучших в своей области. Тем не менее, есть еще проблемы с надежностью автомобилей. Если вы знаете об этом, многие миллионы автомобилей изымаются с рынков для серьезных [ошибок]. В моей машине производитель бесплатно заменит тормозные машинки для всех автомобилей, купленных в том же году.

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

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

Это как все остальное ... когда это работает, тебе все равно ... когда оно сломано (или не работает так, как ты хочешь / ожидаешь), тебе все равно.

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

Это все, где вы выглядите и как вы измеряете.

Это на самом деле довольно просто. Автомобили старые технологии. Конечно, в наши дни есть навороты (эти перерывы), но если вы посмотрите на ранние машины - они много сломались .

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

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

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

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

Если вы изучите теорию надежности, ответ станет ослепительно очевидным. Все механическое (ожидаемое программное обеспечение) обладает стабильной надежностью, то есть частотой отказов за пределами областей детской смертности и износа. Частота отказов конечного элемента - это СУММА частоты отказов деталей. Добавьте больше частей: совокупная частота отказов становится более высокой. Задача состоит в том, чтобы получить очень низкие показатели отказов всех этих компонентов.

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

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

Программное обеспечение, которое не имеет (известных) дефектов, имеет частоту отказов 0. Оно будет работать без сбоев вечно. (Среднее время между отказами = 1 / частота отказов). Аппаратная платформа выйдет из строя первой.

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

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

(Даже такие вещи, как переворачивание битов альфа-частиц в оперативной памяти, - это физическое явление, а не программный дефект. Однако способ обработки такого события МОЖЕТ быть программным дефектом, но помните, что неприятная альфа-частица была просто еще одним входом в программное обеспечение. )

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

С другой стороны,

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

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

И бессмысленно расширять аналогию:

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

Обновления не меняют масло, они исправляют тормоза.

Релизы не меняют масло, они больше похожи на зажигание без ключа.

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

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

Программное обеспечение - это математические и логические объекты, а машины - реальные объекты.

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

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

Вы также можете экстраполировать это сравнение, говоря: «Почему молот надежнее секретаря?».

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

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

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

Все мировые автомобили едва ли по сложности соответствуют оригинальному программному обеспечению Unix.