Чому програмне забезпечення не таке надійне, як автомобіль? [зачинено]

У мене був користувач, який задав мені це питання. Ми знаємо, що машини ламаються, але це через щось фізичне (якщо не задіяно програмне забезпечення!).

Я намагався відповісти, що програмне забезпечення - це набагато молодша галузь, але користувач протиставив, "чи автомобільна промисловість не стала набагато стабільнішою та надійною з меншою кількістю людей?".

Я також намагався відповісти, що програмне забезпечення складніше, але користувач протиставив, що є багато тисяч деталей, які складають машину. Люди, які проектують та будують автомобілі, як правило, дуже добре знають свою складову (частину), але все одно вони працюють як кінцевий результат.

Отже, чому програмне забезпечення не таке надійне, як автомобіль?

Передумова вашого питання просто неправильна: програмне забезпечення не "менш надійне", ніж автомобіль. Існують мільйони на мільярди пристроїв, які впродовж багатьох років працюють із вбудованим програмним забезпеченням 24x7 без проблем. Чорт забираю, деякі з них є в автомобілях, і контролюйте / контролюйте двигун. Отже, як програмне забезпечення може бути менш надійним, ніж автомобіль, якщо автомобілі самі покладаються на програмне забезпечення?

Я проектую програмне забезпечення та механічні деталі.

Це складність.

Тому що в сучасному програмному забезпеченні є мільйони «деталей».

Запчастини до програмного забезпечення дуже складні і мають багато ДЕРЖАВ. Механічна рухома частина не має стану.

Механічна рухома частина має своє положення (одна змінна).

Програма, яка працює і використовує 1 Мб оперативної пам’яті, має стан мільйона байтів. Це набагато більше, ніж будь-яка нормальна механічна система.

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

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

Навіть "привіт світ" працює в операційній системі. Старі 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. Вік поля (конструкція транспортного засобу складає тисячі років; конструкція моторизованих транспортних засобів старша 250 років [парові машини тощо])
8. Критичність підсистем (автомобілі все ще "працюватимуть", навіть якщо значна частина їх деталей перестане працювати - електроблокування, електросклопідйомники, кондиціонер, вентилятор склоочисника, розбиті вікна, загублені ступиці, плоскі шини [надіньте нову], радіо, світло-два, віддалений запис тощо; коли щось на комп’ютері ламається, це часто сценарій SHTF)
9. Взаємозалежність (коли один комп’ютер ламається, не рідко це впливає на сотні чи тисячі інших комп’ютерів; коли одна машина зламається, дещо рідко страждають інші машини - якщо постраждали інші машини, це майже завжди лише 1 -3)
10. Винна винна (якщо одна частина комп’ютера або один комп’ютер з тисячі ламається і шкодить системі, вину поширюється на весь комп'ютер, або в останньому випадку, на всю мережу комп'ютерів; якщо ваш автомобіль вражений автомобілем з невдалі гальма, або якщо машина зупиняється і не запускається на шосе, винна лише окрема частина автомобіля)
11. Кінцеві проти нескінченних систем (машини можуть бути набиті лише стільки, і вони очікують, що працюватимуть лише в обмежених умовах - наприклад, ви не їдете на BMW по місцевості, що може робити тільки автомобіль, подібний до джипа; з комп’ютерами, проте можливості фактично нескінченні - постійно з'являються нові речі, нові API, нові ОС, нові отвори в безпеці, iPad, програмне забезпечення для мобільних телефонів, нове це, нове, що і т. д.)
12. Сфера необхідних знань (людина з IQ 130-140 могла б дізнатися майже все, що потрібно знати про автомобілі, але змогла дізнатись лише частину того, що потрібно знати про комп'ютери та програмування)

Проста причина, чому вся логіка є хибною:

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

Програмне забезпечення з іншого боку має Input -> Process -> Output . Через цю природу систему неможливо повністю передбачити або зрозуміти.

Дональд Рамсфельд сказав, що найкраще:

«Є відомі знання; Є речі, які ми знаємо, ми знаємо. Ми також знаємо, що є відомі невідомі; тобто, ми знаємо, що є деякі речі, про які ми не знаємо. Але є й невідомі невідомі - ті, яких ми не знаємо, ми не знаємо. ”- міністр оборони США Дональд Рамсфельд

Підсумок:

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

Це дурне питання (не від вас, а від оригінальної людини).

Це звучить як мій батько (механік), який ненавидить комп’ютери, але цілий день проводить на eBay.

Це як запитати «Чому дерево надійніше молі?».

Перш за все, у мене є 30 (так, 30+) комп’ютерів, і жоден з них не був у магазині. Я щойно витратив $ 1400 на свій автомобіль на ремонт. Іди порахуй кількість авторемонтних майстерень проти ремонту комп’ютерів. Ще раз дурна аналогія.

Автомобілі виготовлені із сталі, комп'ютери пластикові. Автомобілі працюють у будь-яких погодних умовах, комп’ютери, призначені для використання в приміщенні.

My Commodore 64 (26 років) працює чудово і не має ремонту. Обоє моїх машин (менше 10 років) провели дуже масштабний ремонт. Покажіть мені автомобіль з тисячами і тисячами годин користування, якому вже 26 років, який все ще працює на 100% те саме, що він робив, коли він був новим на заводі.

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

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

Програмне забезпечення здебільшого не має такого поняття, як поступовий збій. Це або працює, або ламається. Поділ на нуль не "майже коректно"; це просто помилка. Коли ви намагаєтесь зберегти на диску без достатнього місця, ви не можете сильно стискати, щоб змусити всі дані в себе; це просто не піде.

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

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

Тоді вам доведеться створити сам орган швидкої допомоги, що також загрожує регуляторними вимогами декількох шарів уряду та інших органів. Хоча все ще задовольняє бажання замовника щодо приємного розташування сидінь або системи зберігання. І не забувайте, що у вас є сотні різних клієнтів у всьому світі, за різними схемами закупівель та розміщення, жоден з яких ніколи не каже "Я візьму ще десяток більше, як останній", не надсилаючи також сторінки винятків, які часто вимагають повного перепланування всієї справи.

Автомобілі? Це банально. Ви купуєте те, що побудовано, і не маєте прямого впливу на жоден аспект дизайну. Навіть ваш вибір кольору є штучним, тому що ви фактично не можете вказати те, що ще не було розроблено та протестовано. У певному сенсі є лише "ринок", а не "клієнт". Я б заперечував, що програмне забезпечення, що виробляється на певному ринку, настільки ж надійне, як і автомобіль, який ви підбираєте у місцевого дилера.

Автомобілі насправді не такі надійні, як ви думаєте. Просто недоліки можуть тривалий час залишатися прихованими (або ігноруватися), не спричиняючи збою всієї справи. Масло та / або теплоносій для вашої машини? Немає? Ти впевнений? Ви, мабуть, помиляєтесь ... Це, мабуть, просто просочилася дуже мала кількість кудись, яку ви ще не помітили ... Тепер поширюйте це на підвіску, кузовні панелі, салон тощо. Я не думаю, що я ніколи все ж натрапив на машину, з якою я не зміг знайти щось не так. Однак переважна більшість деталей зайва місії транспортування. Не так із комп’ютером. Майже кожна частина комп'ютера є критичною.

Це старий аналог проти цифрових дебатів, щойно перепакований. Цифрове телебачення чудово, доки все ідеально. Як тільки щось піде не так, звук заїкається, а відео блокується, роблячи це марним. Порівняйте з аналоговим телебаченням, де ви просто отримаєте трохи шипіння або статику, які легко ігнорувати.

По-перше, звичайно, деякі sw абсолютно надійні, і автомобілі - особливо британські та італійські - не обов'язково такі надійні.

Це сказав, що мій досвід роботи з автомобільним програмним забезпеченням полягає в тому, що він зводиться до двох речей:

• Гарантійні витрати. Коли ваш sw не вдається, ви перезавантажте його. Можливо, ви подасте звіт про помилку. Або скористайтеся дорогим договором підтримки. Коли ваша машина вийде з ладу, ви підвезете її і вимагатимете її встановити під гарантію. Це обійдеться виробнику в 100 доларів і вище. Якщо кожен провал sw коштував виробнику $ 2, я впевнений, що SW був би більш надійним.

• JD Powers (та інші рейтинги якості). JD Powers проводить опитування ThingsGoneWrong (що може бути чим завгодно). І якщо цей рейтинг по-справжньому поганий, люди просто не купуватимуть вашу машину, принаймні, не за достатньо грошей, щоб отримати прибуток. Якби у нас були повноваження JD для sw і люди по-справжньому дбали про це, то я впевнений, що SW був би більш надійним.

Тож якщо ви робите ненадійні автомобілі, гарантійні витрати швидко з’їдуть весь прибуток, і через кілька років рейтинг поганої якості означає, що ви взагалі не будете продавати жодні машини. Якщо ви зробите ненадійний sw, користувачі будуть скаржитися, і ви можете продати дорогі договори підтримки.

Надійність та безпека автомобільних транспортних засобів є обов'язковими. У багатьох (більшості?) Країнах законодавством вимагається, щоб вони мали мінімальний рівень надійності та безпеки, і вони перевіряються на найгірший сценарій (що б там не було). Комерційне програмне забезпечення здебільшого не є.

Хоча існують інші правові наслідки для програмного забезпечення, важливо зауважити, що якщо програмне забезпечення виходить з ладу щоразу, коли ви натискаєте кнопку "Зберегти", це просто питання виправлення / виправлення, і ви продовжуєте продовжувати. Якщо машина врізається кожного разу, коли ви включаєте індикатор, то це набагато гірше . Для Microsoft Outlook просто не так важливо працювати без аварійних збоїв, як для позашляховика, що працює без несподіваної аварії.

При цьому, є й інші програми, які несуть стільки ж, скільки більше відповідальність, ніж механіка автомобіля. Літаки та системи ракетного керівництва повинні бути надійними; є життя на карту! Можна сподіватися, що вони більш жорсткі, ніж середній автомобіль.

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

• Внизу машини не віртуальні, це, мабуть, буде простіше (проте дорожче)
• Вони почали набагато раніше, ніж програмна індустрія, навіть якщо їх було менше, ви не можете мінімізувати практику та знання, які вони зібрали. Програмна індустрія ще немовля порівняно з нею.
• Вся автомобільна індустрія зобов'язана законом і етикою не робити автомобіль, який вбиває їх водія, особливо в останні десятиліття.

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

Що призводить нас до цього: більшість програмного забезпечення не вважається критичним у своїй галузі. Якщо це розглядається як таке, у вас є надійне програмне забезпечення, єдина проблема, яку ви знайдете, - це проблеми, пов'язані з оточенням (тому, якщо ви зможете контролювати це, практично у вас не буде проблем), а не саме програмне забезпечення. Однак більшість редакторів програмного забезпечення не працюють у цій критичній області, звичайно, вони зобов'язані забезпечити певний рівень якості, але вони більше зобов'язані (на мою думку) доставити програмне забезпечення якнайшвидше. Однак хороше програмне забезпечення вимагає: хорошого управління проектами, чітких специфікацій, гарного дизайну та хорошого рівня навичок від тих, хто працює в ньому (щоб відновити його). Це просто, щоб зробити це, ми навіть не говоримо про його продаж ...

На все це потрібен час і так потрібні гроші. Я не кажу, що ти отримуєш те, за що платиш, за що я говорю, більшу частину часу виробляєш те, за що ти інвестуєш, ніколи не менше (за винятком випадків, коли ти накрутився, але потім нічого не виробляєш ...), а іноді й більше. .

Я не вірю, що машини менш складні. Але навіть якщо це так, я не вважаю, що програмне забезпечення є менш надійним. Однак я вважаю, що є більш важливі фактори, які призводять до розбіжностей у надійності програмного забезпечення:

1. Абстракція, що бере участь у програмному забезпеченні. Це змушує розробників програмного забезпечення нерозуміти, як все реально працює. З плином часу додається все більше абстракцій. Наприклад, мова складання дає вам прямий контроль над машиною. C більш абстрагований, але все ще близький до машини. Java, C # і те, що буде далі, сильно скорочують те, що відбувається в машині. Інший приклад - якщо ви програміст, який хоче зрозуміти, як відбувається мережа на програмному рівні, то вам слід знати, що програмувати на C, оскільки інфраструктура (як програмне забезпечення) написана на C.

2. Різний досвіді Знання виробників призводить до різних результатів. Різні розробники створюють програмне забезпечення з різною надійністю. Те саме можна сказати і про виробників автомобілів. Однак різниця полягає в тому, що кожен, хто може використовувати редактор і компілятор або навіть просто встановити IDE (Integrated Environment Environment), може створити програмне забезпечення І безкоштовно. Щоб зробити автомобіль, вам потрібні величезні інвестиції, фабрика (деякі можуть зробити машину, не використовуючи її, але її ви не знайдете навколо себе всюди). Те, що ви вкладете величезні інвестиції, означає, що ви будете намагатися найняти найкращих у цій галузі. Тим не менш, проблеми з надійністю у автомобілів все ще є. Якщо вам це відомо, багато мільйонів автомобілів вилучаються з ринків для серйозних [помилок]. У моїй машині виробник замінить гальмівні ножиці безкоштовно для всіх автомобілів, придбаних в тому ж році.

3. Помилки в програмному забезпеченні, як правило, більше подобаються користувачам, ніж автомобілі. Це результат інтерактивності та реакції між користувачем та програмним забезпеченням. У автомобілі ми звертаємо увагу на меншу кількість деталей на кшталт "Автомобіль прискорюється, коли ми наступаємо на педаль газу", ламання, повороти, вогні, дзеркала та ін. відповідь. Отже, існує багато моментів, коли програмне забезпечення може бути помилковим, і користувач це помітить відразу. Це змушує користувача вважати, що він менш надійний, ніж автомобілі.

4. Злом і напади . Чим ширше використовується програмне забезпечення, тим вищий відсоток він буде піддаватися хакерським атакам. Ви можете порівняти це з крадіжкою автомобіля. Для мене також порушена надійність автомобіля, коли його може відкрити хтось, крім власника чи ключа. Однак спробувати атакувати програмне забезпечення простіше, ніж автомобіль, оскільки зловмисника не видно. Отже, коли програмне забезпечення порушено, люди пов'язують, що воно не є надійним, хоча воно є надійним у тому, для чого воно було зроблене.

Це як все інше ... коли це працює, то тебе не хвилює ... коли він зламаний (або працює не так, як ти хочеш / очікуєш), ти дбаєш.

Подумайте про літаки. Тони людей переживають за те, що люди намагаються викрасти або підірвати їх. Але дійсно кількість негативних подій невелика порівняно з кількістю щоденних рейсів. (Є більше рейсів за один день, тоді їх коли-небудь викрали або бомбили. Хек навіть намагався бути викраденим чи бомбардованим.)

Все в тому, як ти виглядав і як вимірюєш.

Насправді це досить просто. Автомобілі - старі технології. Звичайно, сьогодні є дзвіночки (перерва), але якщо поглянути на ранні машини - вони зламалися дуже багато .

"Технологія", що стоїть за механічними частинами автомобілів, існує вже сотні років, і двигун внутрішнього згоряння існує вже давно, і коли вони були представлені, виникло багато проблем.

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

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

Запитайте будь-якого власника сучасного автомобіля з ECU в ньому, скільки часу його пробіг до дорогої несправності. Я буду приголомшений, якщо ви отримаєте 10 років. Сучасні машини, повні електроніки та датчиків, надзвичайно ненадійні.

Якщо вивчати теорію надійності, відповідь стає сліпучо очевидною. Все механічне (очікуйте програмне забезпечення) має стійкий стан надійності, який є показником відмов, якщо він знаходиться поза межами дитячої смертності та зношеності. Коефіцієнт відмов кінцевого елемента - це SUM коефіцієнта виходу з ладу деталей. Додайте більше деталей: сукупний коефіцієнт відмов стає більшим числом. Завдання полягає в тому, щоб отримати рівень відмов усіх цих компонентів дійсно низький.

Якщо мова йде про такі речі, як ремені ГРМ, датчики зносу циліндрів і кисневі датчики, вони заповнюються лайно, а роз'єми йдуть омічними, а обриви проводів через вібрацію - є методи, які можна використовувати для зниження частоти відмов. У той же час вартість також зростає.

Програмне забезпечення, з іншого боку, має постійний рівень відмов. Незважаючи на труднощі в пошуку дефектів часом, врешті-решт все програмне забезпечення - це ковбасний верстат. Вхідні дані -> Робити речі -> Виходи. Іноді ЗАМОВЛЕННЯ входів та комбінацій входів призводить до збоїв у режимах, які можна виявити. Коли це трапляється, ви виявили свій дефект, виправляєте його та рухаєтесь далі.

Програмне забезпечення, яке не має (відомих) дефектів, фактично має коефіцієнт відмов 0. Він буде працювати вічно без збоїв. (Середній час між відмовами = 1 / коефіцієнт відмов). Першою буде вийти з ладу апаратна платформа.

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

ПОЛОЖЕННЯ у всьому цьому полягає у тому, щоб спробувати порівняти коефіцієнти відмов фізичних речей (спричинених зносом, міграцією металу в ІС, потраплянням води, вібрацією тощо) зі ступенем виходу з ладу того, що по суті є кінцевим станом, який просто робить саме що підказує його послідовність інструкцій.

(Навіть такі речі, як альфа-частинки, що перегортають біти в оперативній пам’яті, - це фізичне явище, а не дефект програмного забезпечення. Спосіб обробки такого рівномірного МОЖЕ бути дефектом програмного забезпечення, але пам’ятайте, що бридка альфа-частинка була лише черговим входом у програмне забезпечення. )

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

З іншого боку,

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

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

І безглуздо продовжувати аналогію:

Патчі не змінюють масло, вони замінюють герметичну прокладку.

Оновлення масла не змінюють, вони фіксують гальмо.

Випуск не змінює масло, вони більше схожі на додавання запалювання без ключа.

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

Крім того, програмне забезпечення, як правило, підлаштовується, у вас немає 10000000 різних моделей автомобілів. Я б сказав, що wikimedia є надійною, і тоннами ppl використовується це програмне забезпечення. Отже, ви можете сказати, що багато людей використовують помилку або надійне програмне забезпечення. (wordpress, різні управління джерелами, mysql та sqlite досить надійні тощо)

Програмне забезпечення - це математичні та логічні об'єкти, а машини - реальні об'єкти.

Крім того, ви можете легко дізнатися, коли у машини є проблема, а в чому проблема, тоді як це може бути набагато складніше з програмним забезпеченням: уявіть, що хтось має проблеми з комп’ютером, а хтось із проблемою з автомобілем; ця людина може краще знати, що не так, оскільки машини менш абстрактні, ніж комп'ютери.

Я не кажу, що комп'ютери важче зрозуміти: автомобілі також передбачають багато фізичних законів, таких як термодинаміка, електроніка, хімія.

Ви можете також екстраполювати це порівняння, сказавши: "чому молоток надійніший за секретаря?".

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

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

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

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