Здравствуйте, okon, Вы писали:

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

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

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

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


Всё до безумия просто. Вот есть у нас, допустим, программист-бракодел Вася.
1. Вася пишет свою игру и хочет продать её за "дофига денег" в размере $2000. В процессе написания кода монетизации Вася сделает ошибку, при которой у него пользователям не будет показываться реклама. Это будет критическая ошибка для бизнеса, но пользователи ничего особо не заметят. Вася не будет получать доход от рекламы, пока не поправит ошибку, что будет стоить ему $100, но мир даже не заметит этот баг.
2. Вася поправил ошибку, теперь реклама показывается на весь экран и не убирается. Пользователи, увидев такую фигню, массово свалили. Игровой бизнес Васи разрушен, он "потерял" $2000, но миру всё ещё пофиг.
3. Потеряв надежду найти себя в бизнесе, но приобретя опыт, Вася устроился на работу в крупную игровую контору. Там его поставили писать игровой чат и, через некоторое время, Вася "положил" этот чат на целые сутки. Рейд-группа, бившая крупного босса, осталась без нормального взаимодействия, завалила бой, пошла на игровой форум и крупно "нагадила в сообщения". Продажи игры упали, примерный ущерб владельцы бизнеса оценили в $4000. Васе сказали, какой он нехороший человек. Мир погудел пару дней о "криворуких программистах" и забыл эту тему.
4. Васю, тем временем, перевели на правки сетевого протокола игры, где он через некоторое время также отличился. В течение выходных игра работала криво, что привело к массовому оттоку пользователей. Примерный ущерб составил порядка $100000. Руководство начало что-то подозревать, и решило уволить Васю "от греха подальше".
5. Через некоторое время Вася по знакомству устроился на работу в банк. Там тоже всё шло не очень гладко — из-за его ошибки упал модуль процессинга всех оплат и банк 1 час работал "вхолостую". Ущерб от отказа оставил несколько миллионов баксов. Васю опять уволили, популярное намекнув, что программирование — не его.
6. Перечитав в больнице много умных книжек Вскоре, неунывающий Вася нашёл новую работу. Он устроился разработчиком систем Искусственного Интеллекта в секретный проект по автоматизации систем управления ядерными реакторами... Через некоторое время прибывшая на Земню инопланетная экспедиция с прискорбием констатировала отсутствие на планете жизни.

Так вот. На любом из этих этапов к Васе можно было приставить мегакрутого программиста, который ревьювал бы его код и не допустил бы ни одной их этих ошибок. Вот только затраты на этого мегаспеца за период ревью Васиного кода составили бы, допустим, $5000 в каждом случае. А есть ещё менее бракоделистые программисты, код которых ревьювался бы вхолостую, за те же деньги.
Но конкретно для данного примера, думаю, понятно, что в первом и втором случае найм мегаспеца не оправдался бы ни при каких обстоятельствах. В третьем — тоже крайне спорно. С одной стороны, оценённый ущерб явно оправдывает разгильдяйство руководства, а с другой, могло и посильнее выстрелить, если бы чат отвалился в момент какого-нибудь массового эвента. А вот начиная с 4-го этапа уже да, без ревьювера кода обойтись уже тяжело. Критичный для крупного бизнеса функционал надо защищать от кривых ручек. Особенно если быстро внести правки невозможно.

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