Dlaczego oprogramowanie nie jest tak niezawodne jak samochód? [Zamknięte]

Kazałem użytkownikowi zadać mi to pytanie. Wiemy, że samochody psują się, ale dzieje się tak z powodu czegoś fizycznego (chyba że dotyczy oprogramowania!).

Próbowałem odpowiedzieć, że oprogramowanie jest znacznie młodszą branżą, ale użytkownik odpowiedział: „Czy przemysł samochodowy nie stał się znacznie bardziej stabilny i niezawodny przy mniejszej liczbie ludzi?”.

Próbowałem także odpowiedzieć, że oprogramowanie jest bardziej złożone, ale użytkownik odparł, że jest wiele tysięcy części, które składają się na samochód. Ludzie, którzy projektują i konstruują samochody, po prostu bardzo dobrze znają swoje komponenty, ale nadal wszyscy razem pracują jako efekt końcowy.

Więc dlaczego nie jest tak wiarygodne, jak oprogramowanie samochodu?

Przesłanka twojego pytania jest po prostu nieprawidłowa: oprogramowanie nie jest „mniej niezawodne” niż samochód. Istnieją miliardy na miliardy urządzeń z wbudowanym oprogramowaniem 24x7, bez końca przez lata. Do licha, niektóre z nich są w samochodach i kontrolują / monitorują silnik. Jak więc oprogramowanie może być mniej niezawodne niż samochód, jeśli same samochody polegają na oprogramowaniu?

Projektuję oprogramowanie i części mechaniczne.

To jest złożoność.

Ponieważ w nowoczesnym oprogramowaniu są miliony „części”.

Części oprogramowania są bardzo skomplikowane i mają wiele stanów. Mechaniczna nieruchoma część nie ma stanu.

Mechaniczna część ruchoma ma swoje położenie (jedna zmienna).

Program, który działa i używa 1 MB pamięci RAM, ma milion bajtów stanu. To znacznie więcej niż jakikolwiek normalny układ mechaniczny.

Będzie kombinacja stanów, które nigdy nie zostaną przetestowane, ponieważ zdarzają się tak rzadko. W układzie mechanicznym (jak samochód) łatwo jest sprawdzić, czy części mechaniczne nie uderzają o siebie podczas pracy. Mechaniczne oprogramowanie CAD, którego używam w pracy, robi to automatycznie.

Jeśli zbudowałeś maszyny z niewidzialnych, niedotykalnych części i miałeś miliony ruchomych części, które po prostu za sobą tęskniły, byłby to prosty program.

Nawet „witaj świecie” działa w systemie operacyjnym. Stare 8-bitowe systemy i minikomputerowe systemy operacyjne były dość niezawodne, ponieważ były proste.

Rzeczy takie jak biblioteki DLL i biblioteki współdzielone są zastępowane w ramach aktualizacji wirusów lub instalacji oprogramowania, a następnie program, o który chodzi, nie działa. Trochę jak zmiana opony w samochodzie na oponę rowerową. Niektóre stany krawędzi funkcji biblioteki zakłócają (nie postępuj zgodnie z oczekiwaniami programu).

Programy napisane w językach takich jak Java, które nie pozwalają na wiele nie zaprojektowanych interakcji między obiektami (ponowne użycie wskaźnika, przepełnienie granic tablic) są ogólnie dość niezawodne, gdy w ogóle je uruchomisz.
Kiedy używasz systemów operacyjnych z bibliotekami statycznymi, po uruchomieniu program po prostu nadal działa (ale nadal będzie miał wiele warunków brzegowych, w zależności od wielkości stanu).

Dave Parnas pisze o uzyskaniu niezawodności oprogramowania poprzez zmniejszenie stanu programu. Faceci od ścisłego programowania funkcjonalnego robią to samo, wymuszając pojedyncze przypisanie statyczne.

To kwestia wyboru konsumenta.

Gdyby klienci żądali, aby oprogramowanie było tak niezawodne jak moja Honda Civic (w przeciwieństwie do mojego starego Forda Mavericka), byłoby to możliwe. Niektóre organizacje wymagają oprogramowania, które jest niezawodne, i dostają je, zazwyczaj do oprogramowania wbudowanego, czasami do kluczowych dla bezpieczeństwa rzeczy, takich jak misje kosmiczne i kontrola ruchu lotniczego. Oprogramowanie wciąż nie jest idealne, ale samochody też nie.

Jednak klienci wymagają innych cech swojego oprogramowania i przeważnie nie są skłonni płacić za oprogramowanie, które jest prawdopodobnie mniej funkcjonalne, z pewnością droższe, i jest dostarczane później tylko dlatego, że jest bardziej niezawodne.

Istnieje wiele tysięcy części, które składają się na samochód.

Gdyby tylko komputer (i powiązane oprogramowanie) było takie proste.

Komputer ma gigabajt pamięci? Miliardy klapek? Terabajt dysku? Tryliony „ruchomych” części?

Oprogramowanie może mieć uruchomione dziesiątki tysięcy lub setki tysięcy pojedynczych linii kodu. Plus tyle (lub więcej) testów jednostkowych i narzędzi.

Nie. Argument „samochody też są skomplikowane” jest piętrowy. Oprogramowanie jest o wiele, wiele, dużo bardziej złożone niż samochód.

Zasady, dzięki którym działają silniki spalinowe, i wszystkie elementy składające się na samochód niewiele się zmieniły w ostatnim stuleciu. Oczywiście wprowadzono ewolucyjne ulepszenia i samochody hybrydowe, ale podstawowe elementy są takie same. Masz silnik, układ napędowy itp. Nawet samochody koncepcyjne i twój bardzo drogi, wyjątkowo szybki Bugatti Veyron mają tę samą podstawową budowę. Krótko mówiąc, projektowanie samochodu to dobrze znany problem .

Porównaj to z tworzeniem oprogramowania.

• Klienci nie wiedzą, czego chcą, kiedy zaczynają. Zaczynają mówić o luksusowym odrzutowcu, ale kiedy zdają sobie sprawę z kosztów, chcą, żebyś je zbudował na koszt skutera napędzanego nogą.
• Projekt samochodu zajmuje lata, aby przejść od pomysłu do samochodu koncepcyjnego, a kolejne lata, aby je wyprodukować. Kiedy ostatni raz miałeś ten luksus z oprogramowaniem?
• Części samochodowe są odlewanymi kawałkami metalu, ale komponenty oprogramowania mogą często zmieniać kształt i interfejs.
• Proces produkcji jest zupełnie inny. W samochodach części są wytwarzane w ilościach masowych i te same elementy są stosowane w różnych pojazdach. W oprogramowaniu prawie wszystko jest ręcznie wykonane, ponieważ w przeciwnym razie rzeczy po prostu nie pasują.

Krótko mówiąc, istnieje wiele powodów, dla których samochód byłby postrzegany jako „bardziej niezawodny” niż oprogramowanie. Właśnie wymyśliłem parę.

Samochody są niezawodne. Podobnie jak większość oprogramowania.

Ale ... niestandardowe samochody i niestandardowe oprogramowanie mają swoje problemy.

Każdy prawdziwy entuzjasta samochodów, który ma zmodyfikowany samochód z 1970 roku, majsterkowicza i poprawki, ma awarie i wszelkiego rodzaju głupie problemy, których nie miałby, gdyby pozostawił to oryginalne. Ale ... wtedy nie miałby doładowania ...

Ponieważ samochód, którym jeździsz, był wielokrotnie produkowany, proces budowy jest tak dopracowany, że ten sam samochód może być produkowany na linii produkcyjnej w kółko.

Jeśli byłby to jedyny w swoim rodzaju kompleksowy, najnowocześniejszy samochód, zbudowany od zera, gdy byłby tak blisko niezawodny, na przykład spójrz o ile wyższy jest wskaźnik awaryjności w samochodach wyścigowych Formuły 1. Często zdarza się, że jeden lub dwa rozpadają się na rasę.

Nowe oprogramowanie jest zawsze jednorazowe. To, co koduje programiści, nigdy wcześniej nie było przez nich kodowane. Osiągnięcie naprawdę wysokiej jakości w tym scenariuszu wiąże się z nadmiernym kosztem w przypadku większości produktów. Każde nietrywialne nowe oprogramowanie jest faktycznie prototypem.

Nawiasem mówiąc, jest to jeden z głównych powodów, dla których zastosowanie tradycyjnych technik inżynierii do inżynierii oprogramowania jest katastrofą.

1. Producenci samochodów dopracowują całą specyfikację, zanim wyprodukują „końcowy” produkt.
2. Użytkownicy samochodów nie robią głupot, których projektanci się nie spodziewali.
3. Samochody są „aktualizowane” tylko raz w roku (zazwyczaj), podczas gdy większość oprogramowania powinna być aktualizowana wiele razy w roku.

Mógłbym kontynuować, ale moja przeglądarka ma wrażenie, że zaraz się zawiesi ...

Jest tak naprawdę bardzo prosty powód.

Oprogramowanie, które zarabia pieniądze, to oprogramowanie, które zdobywa udział w rynku. Najczęściej firma, która jako pierwsza wprowadza na rynek oprogramowanie, będzie miała największy udział w rynku, nawet jeśli ich oprogramowanie nie jest najlepszym produktem na danym rynku.

W związku z tym nacisk kładziony jest na wcześniejsze wydanie oprogramowania niedoskonałego, a nie późniejszego i idealnego.

Do tej pory podoba mi się większość odpowiedzi. Oto moja uwaga.

Koszt awarii jest większy w przypadku samochodów niż oprogramowania

Awaria samochodu może potencjalnie kosztować życie. Nawet awaria pojazdu nie zagrażająca życiu stanowi wysoce widoczną niedogodność dla użytkownika. Awaria oprogramowania oznacza po prostu, że jakiś słaby poziom wsparcia produkcji będzie musiał pracować w nadgodzinach. A jeśli ta osoba jest pracownikiem zwolnionym w pełnym wymiarze godzin, to niech to wcale nie będzie takie drogie. W rzeczywistości nagradzana jest zła jakość i złe zarządzanie, ponieważ bezpłatne nadgodziny faktycznie zmniejszają koszty pracy na godzinę!

Oczywiście zależy to od rodzaju używanego oprogramowania (oprogramowanie zasilające systemy uzbrojenia, awionikę lub systemy medyczne może również mieć wpływ na życie), ale samochód kosztuje sporo pieniędzy i jest używany wystarczająco regularnie, aby stracić niezawodność całkiem namacalne i bolesne. Awarie oprogramowania często mają obejścia.

Inna myśl: samochody wydają się niezawodne, ale mają określone koszty utrzymania, które trwają, nawet jeśli samochód działa dobrze, a kulturowo jest to akceptowane, a nawet dumne wydatki osób dbających o swoje pojazdy. Z drugiej strony oprogramowanie jest często zepsute po zainstalowaniu i często musi się zmieniać z czasem, ale kulturowo nikt nie chce płacić za utrzymanie.

Cóż, samochody były dość zawodne przez większą część swojej historii, a na pewno jest krzywa uczenia się. Samochody są produkowane na dużą skalę od około 60 lat, podczas gdy oprogramowanie jest produkowane na dużą skalę tylko przez około 20-25 lat. Mówiąc na dużą skalę, mam na myśli wystarczająco duże masy, które kupują / wykorzystują go i istnieje naprawdę ogromna zachęta, aby dowiedzieć się, jak udoskonalić procedurę jego tworzenia.

Lubię myśleć o samochodzie jako o aplikacji. Podczas gdy system operacyjny jest drogą, na której działa aplikacja.

Interfejs między drogą a samochodem jest dobrze zdefiniowany. Dobrze przetestowany i jest dokładnie sprawdzany pod kątem zgodności wstecznej (co jest łatwe, ponieważ interfejs jest prosty). Ale mimo to masz pewne problemy ze zgodnością wsteczną. Samochody typu „Farrie” mają trudności z jazdą po drogach typu „błotniste drogi”.

Mimo to system operacyjny, podobnie jak drogi, wymaga stałej konserwacji. Wyprzedzają mosty. Samochody zakładają łańcuchy śniegowe i niszczą drogi, powodując uszkodzenie aplikacji i uszkodzenie dysków i plików używanych przez system operacyjny.

Aplikacje będą pisane w jednym systemie operacyjnym. Ale ogólnie muszą one uruchamiać różne wersje systemu operacyjnego (różne typy dróg). Tak więc aplikacja zoptymalizowana na kolację może działać płynnie i bez problemów, o ile działa na odpowiednim systemie operacyjnym (autostrady), podczas gdy inny kod ogólnego przeznaczenia (prostszy) będzie działał poprawnie na wszystkich rodzajach dróg.

Interfejs między aplikacją a systemem operacyjnym jest zdefiniowany, ale niezwykle złożony i zawsze nieznacznie się waha. Zwłaszcza, że ​​zezwalamy użytkownikowi na modyfikowanie własnego systemu operacyjnego za pomocą rozszerzeń. Gdyby rząd zezwolił użytkownikom na modyfikację dróg, nastąpiłoby znacznie więcej awarii.

Kiedy zaczniesz ograniczać zdolność użytkownika do modyfikowania systemu operacyjnego, niezawodność aplikacji może stać się niemal solidna. Spójrz na wszystkie te urządzenia osadzone. Nie zezwalamy użytkownikom w pobliżu ich systemu operacyjnego, a Ty działa dobrze i nieprzerwanie 24/7 bez przerwy.

Powiedziałbym więc, że nie jest to oprogramowanie niewiarygodne. To bardziej przypomina stwierdzenie, że użytkownicy wykopują dziury na autostradzie dla aplikacji. Hej, twoja aplikacja właśnie uderzyła w dziurę, którą wykopałem w zeszłym roku i zapomniałem .

Po pierwsze, użytkownik musi wiedzieć, że na świecie istnieje oprogramowanie tak niezawodne, że nawet nie zdaje sobie z tego sprawy. Czy widziałeś kiedyś awarię telewizora? Ja też nie.

Myślę, że głównym powodem jest to, że oprogramowanie jest nieistotne. Nieistotność oznacza, że ​​osoby, które nie są programistami, nie widzą postępów. Na przykład, gdybym robił samochód, widziałbyś, jak składam różne części i wyglądałby coraz bardziej jak samochód; Jeśli jednak spojrzysz na moje programowanie, być może spędzę godziny przeklinając na czarnym ekranie z zielonym tekstem robiącym dziwne wzory, a potem nagle, gdy wzór zmieni się tylko trochę, nadmiernie się podekscytuję.

Z tego powodu normalni ludzie nie zdają sobie sprawy ze złożoności oprogramowania. Kiedy widzą okno, myślą, że widzą program jako całość, co jest nie tak.

Ponadto oprogramowanie jest znacznie, znacznie częściej dostosowywane do potrzeb klienta niż samochody. Dostosowując samochód, nie będziesz przeciwny jego projektowi, ponieważ byłoby to wyraźnie głupie. Jeśli mój silnik znajduje się z przodu samochodu, przesunięcie go do tyłu najprawdopodobniej będzie ogromną katastrofą. Ponieważ jednak oprogramowanie jest nieistotne, jeśli klient poprosi cię o zrobienie czegoś całkowicie wbrew projektowi, nie otrzyma żadnych wskazówek (oprócz ciebie, ale nie będzie słuchać), że to, co robią, jest głupie, a wtedy „ Zaskoczę się, że to nie działa zgodnie z oczekiwaniami.

1. Brak wymiany informacji (programiści latają solo lub w małych grupach - projektanci samochodów pracują z połączonymi zespołami w dużej korporacji i wszyscy dzielą się swoją wiedzą; gdybyśmy wszyscy pracowali dla dużych korporacji, wszyscy bylibyśmy lepszymi programistami dzięki nauce od innych; dlatego też takie rzeczy jak programy open source i zasoby online są bardzo ważne)
2. Oczekiwania uczestników rynku (jest ok, jeśli projektant samochodu jest tylko nieznacznie przydatny przez pierwsze 5-10 lat, ale jeśli programista pójdzie na rozmowę kwalifikacyjną i stwierdzi, że nie będzie przydatny przez 5-10 lat, wywiad się skończył)
3. Brak testów penetracyjnych (z powodu braku funduszy, problemów z legalnością itp .; producenci samochodów jednak uderzają samochód za samochodem w ścianę z cegieł, mają tunele aerodynamiczne, mają stosunkowo proste wymagania dotyczące wydajności itp.)
4. Przejrzystość informacji (nie wiesz, jak działa większość oprogramowania; zgadujesz lub przyjmujesz założenia w oparciu o wywiady, komunikaty prasowe, reklamy itp. W przypadku samochodów, jednak większość rzeczy jest tam do obejrzenia)
5. Nieodłączna enkapsulacja wiedzy (facet / robot spawający ramę nie musi znać matematyki stojącej za systemem kontroli stabilności; programiści muszą mieć wiedzę na temat tysięcy lub dziesiątek tysięcy rzeczy nieznanych przeciętnemu człowiekowi, podczas gdy tylko projektanci samochodów muszą wiedzieć setki lub tysiące)
6. Namacalność (pomaga, kiedy ją widzisz)
7. Age of Field (konstrukcja pojazdu ma tysiące lat; konstrukcja pojazdu silnikowego ma ponad 250 lat [silniki parowe itp.])
8. Krytyczność podsystemów (samochody nadal będą „działać”, nawet jeśli wiele ich części przestanie działać - elektrozaczepy, elektryczne szyby, HVAC, wycieraczki przedniej szyby, wybite szyby, zgubione kołpaki, płaskie opony [na nowe], radio, światło lub dwa, zdalne wejście itp .; gdy coś się psuje, często jest to scenariusz SHTF)
9. Współzależność (gdy jeden komputer się psuje, nierzadko wpływa on na setki lub tysiące innych komputerów; gdy jeden samochód się psuje, jest to dość rzadkie, że dotyczy to innych samochodów - jeśli dotyczy to innych samochodów, prawie zawsze jest to tylko 1 -3)
10. Blanket Blame (jeśli jedna część komputera lub jeden z tysięcy komputerów psuje się i rani system, wina rozciąga się na cały komputer, lub w tym drugim przypadku na całą sieć komputerów; jeśli samochód uderzy samochód z nieudane hamulce lub jeśli samochód utknie i nie uruchomi się ponownie na autostradzie, obwiniana jest tylko pojedyncza część samochodu)
11. Systemy skończone vs. nieskończone (samochody mogą mieć tylko tyle miejsca i oczekuje się, że będą działać tylko w ograniczonych warunkach - np. Nie jeździsz BMW po terenie, który może zrobić tylko pojazd podobny do dżipa; z komputerami, możliwości są de facto nieskończone - cały czas pojawiają się nowe rzeczy, nowe interfejsy API, nowe systemy operacyjne, nowe luki w zabezpieczeniach, iPady, oprogramowanie telefonu komórkowego, nowe to, nowe to itd.)
12. Zakres wymaganej wiedzy (osoba z IQ 130-140 mogłaby nauczyć się prawie wszystkiego, co trzeba wiedzieć o samochodach, ale mogła nauczyć się tylko ułamka tego, co należy wiedzieć o komputerach i programowaniu)

Prosty powód, dla którego cała logika jest wadliwa:

Urządzenia mechaniczne można po prostu zredukować do wejścia / wyjścia ; zwiększenie liczby części w celu osiągnięcia tej operacji We / Wy nie zmienia operacji We / Wy. W ten sposób system można w pełni zrozumieć.

Z drugiej strony oprogramowanie ma Input -> Process -> Output . Z powodu tej natury nie można w pełni przewidzieć ani zrozumieć systemu.

Donald Rumsfeld powiedział najlepiej:

„Znane są znane; są rzeczy, o których wiemy, że wiemy. Wiemy również, że znane są niewiadome; to znaczy wiemy, że są pewne rzeczy, których nie wiemy. Ale są też nieznane niewiadome - te, o których nie wiemy, nie wiemy. ”- Sekretarz Obrony USA Donald Rumsfeld

W podsumowaniu:

• Mechaniczne urządzenie to system, który ma znane i nieznane,
• Oprogramowanie ma powyższe, ale także nieznane nieznane.

To głupie pytanie (nie od ciebie, ale od pierwotnej osoby).

To brzmi jak mój ojciec (mechanik), który nienawidzi komputerów, ale spędza cały dzień w serwisie eBay.

To jak pytanie „Dlaczego drzewo jest bardziej niezawodne niż ćma?”.

Przede wszystkim mam 30 (tak, ponad 30) komputerów i żaden z nich nie był w sklepie. Właśnie wydałem 1400 $ na mój samochód na naprawy. Idź policzyć liczbę warsztatów samochodowych vs naprawy komputera. Jeszcze raz głupia analogia.

Samochody są wykonane ze stali, komputery plastikowe. Samochody pracują w każdych warunkach pogodowych, komputery przeznaczone do użytku w pomieszczeniach.

Mój Commodore 64 (26 lat) działa idealnie i nie został naprawiony. Oba moje pojazdy (mające mniej niż 10 lat) zostały bardzo szeroko naprawione. Pokaż mi samochód z tysiącami godzin użytkowania, który ma 26 lat i nadal działa w 100% tak samo, jak wtedy, gdy był fabrycznie nowy.

Oprogramowanie oparte jest na bitach: 0 i 1. Samochody oparte są (głównie) na częściach mechanicznych.

Część mechaniczna może się zużyć lub działać nieprawidłowo i nadal stanowić rodzaj pracy. Hamulce się zużyją lub zawór przecieka, ale samochód nadal działa, dopóki nie będzie można go naprawić.

Oprogramowanie w większości nie ma czegoś takiego jak stopniowa awaria. To albo działa, albo psuje się. Dzielenie przez zero nie jest „prawie poprawne”; to tylko błąd. Podczas próby zapisania na dysku bez wystarczającej ilości miejsca nie można mocno ścisnąć, aby zmusić wszystkie dane; to po prostu nie pójdzie.

Nie sądzę, aby oprogramowanie było mniej niezawodne niż samochód, ale gdy zawodzi, zawodzi natychmiast, a nie stopniowo.

Myślę, że mam znacznie lepszą analogię. Weź firmę produkującą karetki pogotowia zgodnie ze specyfikacją klienta. Platforma podstawowa (powiedzmy, w pełni sprawne i zgodne z prawem podwozie z wycięciem na samochód kempingowy) wymaga modyfikacji w kilku punktach: rama, system ładowania, dziobek wlewu, zawieszenie itp. Modyfikacje te muszą nie tylko być zgodne z prawem ulicznym, ale spełniać wymagania jurysdykcyjne jednocześnie zaspokajając pragnienia klientów.

Następnie musisz zbudować sam korpus pogotowia, który jest również wypełniony wymogami regulacyjnymi ze strony kilku organów rządowych i innych organów. Wciąż zaspokajając życzenia klientów dotyczące stylowego układu siedzeń lub systemu przechowywania. I nie zapominaj, że masz setkę różnych klientów z całego świata, korzystających z różnych harmonogramów zakupów i wdrażania, z których żaden nigdy nie mówi „wezmę jeszcze kilkanaście więcej niż ostatni”, nie podając także stron wyjątków, które często wymagają pełnego przeprojektowania całości.

Samochody? To banalne. Kupisz to, co zbudowane i nie masz bezpośredniego wpływu na żaden aspekt projektu. Nawet wybór koloru jest sztuczny, ponieważ nie można tak naprawdę określić czegoś, co nie zostało jeszcze zaprojektowane i przetestowane. W pewnym sensie istnieje tylko „rynek”, a nie „klient”. Twierdziłbym, że gotowe oprogramowanie produkowane na niektóre rynki jest zasadniczo tak samo niezawodne jak samochód, który odbierasz u lokalnego dealera.

Samochody nie są tak niezawodne, jak myślisz. Po prostu usterki mogą pozostać ukryte przez długi czas (lub zignorowane) bez powodowania awarii. Twój samochód wycieka olej i / lub płyn chłodzący? Nie? Jesteś pewny? Prawdopodobnie się mylisz ... Prawdopodobnie wyciek gdzieś bardzo małej ilości, której jeszcze nie zauważyłeś ... Teraz rozciągnij to na zawieszenie, panele nadwozia, wnętrze itp. Nie sądzę, żebym kiedykolwiek ale napotkałem samochód, z którym nie mogłem znaleźć nic złego. Jednak zdecydowana większość części jest zbyteczna dla misji transportu. Nie tak z komputerem. Prawie każda część komputera jest krytyczna.

To stara debata analogowo-cyfrowa, właśnie zapakowana. Telewizja cyfrowa jest świetna, o ile wszystko jest idealne. Gdy tylko coś pójdzie nie tak, dźwięk się zacina, a wideo blokuje się, czyniąc go bezużytecznym. Porównaj z telewizją analogową, w której dostaniesz trochę syku lub szumu, który łatwo można zignorować.

Po pierwsze, niektóre SW są całkowicie niezawodne, a samochody - zwłaszcza brytyjskie i włoskie - niekoniecznie są tak niezawodne.

To powiedziawszy, moje doświadczenie w pracy z oprogramowaniem motoryzacyjnym polega na tym, że sprowadzają się one do dwóch rzeczy:

• Koszty gwarancji Kiedy twój sw zawiedzie, uruchom go ponownie. Być może wyślesz raport o błędzie. Lub skorzystaj z drogiej umowy wsparcia. Gdy twój samochód zawiedzie, przyniesiesz go i zażądasz naprawy w ramach gwarancji. Będzie to kosztować producenta 100 USD i więcej. Jeśli każda awaria SW kosztuje producenta 2 USD, jestem pewien, że SW byłby bardziej niezawodny.

• JD Powers (i inne rankingi jakości). JD Powers ankiety ThingsGoneWrong (które może być cokolwiek). A jeśli ten ranking jest naprawdę zły, ludzie po prostu nie kupią twojego samochodu, a przynajmniej nie za wystarczająco dużo pieniędzy, aby zarobić. Gdybyśmy mieli moc JD dla sw i ludzie naprawdę się tym przejmowali, jestem pewien, że sw byłby bardziej niezawodny.

Jeśli więc produkujesz niewiarygodne samochody, koszty gwarancji szybko pochłoną wszystkie Twoje zyski, a za kilka lat zła jakość rankingu oznacza, że ​​nie sprzedajesz żadnych samochodów. Jeśli zrobisz niewiarygodnego sw, użytkownicy będą narzekać i będziesz mógł sprzedawać drogie umowy wsparcia.

Wymagana jest niezawodność i bezpieczeństwo pojazdów silnikowych. W wielu (większości?) Krajach prawo wymaga, aby miały one minimalny poziom niezawodności i bezpieczeństwa oraz były testowane pod kątem najgorszego scenariusza (cokolwiek to jest). Oprogramowanie komercyjne w większości nie jest.

Chociaż istnieją inne prawne konsekwencje dla oprogramowania, należy pamiętać, że jeśli oprogramowanie ulega awarii za każdym razem, gdy naciśniesz przycisk „Zapisz”, to jest to po prostu kwestia łatki / poprawki, a następnie kontynuujesz. Jeśli samochód ulega awarii za każdym razem, gdy włączasz wskaźnik, jest to o wiele gorsza rzecz. Po prostu nie jest tak ważne, aby program Microsoft Outlook działał bez nieoczekiwanego awarii, tak jak ma to miejsce w przypadku SUV-a bez nieoczekiwanej awarii.

To powiedziawszy, istnieją inne programy, które mają taką samą lub większą odpowiedzialność niż mechanika samochodu. Samoloty i systemy naprowadzania na pociski muszą być niezawodne; stawką jest życie! Można mieć nadzieję, że są one bardziej rygorystycznie testowane niż przeciętny samochód.

Przemysł samochodowy nie wypuszcza publicznie samochodu „beta” do testowania, przemysł samochodowy nie musi też martwić się o środowisko, w którym dostarczają swoje produkty, jednak muszę martwić się o wiele innych rzeczy. powiedzmy, że branża oprogramowania różni się zasadniczo (jak wszyscy wiemy), więc niezawodność i złożoność są naprawdę sugestywne. Moim zdaniem samochód jest tak złożony jak oprogramowanie, ale od tego czasu łatwiej jest zobaczyć, co działa

• Samochody na dole nie są wirtualne, z pewnością łatwiej będzie je przetestować (ale drożej)
• Zaczęli znacznie wcześniej niż przemysł oprogramowania, nawet jeśli było ich mniej, nie można zminimalizować zgromadzonej praktyki i wiedzy. Przemysł oprogramowania jest wciąż dzieckiem w porównaniu do niego.
• Cały przemysł samochodowy jest związany prawem i etyką, aby nie produkować samochodu, który zabija ich kierowcę, szczególnie w ostatnich dziesięcioleciach.

Zatem stwierdzenie, że oprogramowanie jest mniej niezawodne niż samochody, może być prawdziwe dla wielu rodzajów oprogramowania i całkowicie błędne dla innych obszarów (bezpieczeństwo, lotnictwo ...) możesz być pewien, że oprogramowanie jest przynajmniej najbardziej niezawodne niż najbardziej niezawodne samochodów w tym obszarze. Po prostu dlatego, że te obszary są krytyczne i z tego, co wiem tylko w tym obszarze, oprogramowanie można porównać do przemysłu samochodowego.

Co prowadzi nas do tego: większość programów nie jest uważana za krytyczną w swojej dziedzinie. Gdy jest to traktowane jako takie, masz niezawodne oprogramowanie, jedynym problemem, jaki możesz na nich znaleźć, są problemy związane ze środowiskiem (więc jeśli możesz je kontrolować, praktycznie nie będziesz mieć problemu), a nie samo oprogramowanie. Jednak większość edytorów oprogramowania nie działa w tych krytycznych obszarach, oczywiście są zobowiązani do zapewnienia określonego poziomu jakości, ale są bardziej zobowiązani (moim zdaniem) do dostarczenia oprogramowania tak szybko, jak to możliwe. Jednak dobre oprogramowanie wymaga: dobrego zarządzania projektami, solidnych specyfikacji, dobrego projektu i dobrego poziomu umiejętności pracujących w nim osób (aby go wznowić). Żeby to zrobić, nie mówimy nawet o sprzedaży ...

Wszystko to wymaga czasu i dlatego wymaga pieniędzy. Nie mówię, że dostajesz to, za co płacisz, przez większość czasu produkujesz to, na co inwestujesz, nigdy nie mniej (z wyjątkiem tego, że się pieprzysz, ale wtedy nic nie produkujesz, więc ...), a czasem więcej. .

Nie sądzę, aby samochody były mniej skomplikowane. Ale nawet jeśli tak jest, nie sądzę, że oprogramowanie jest mniej niezawodne. Uważam jednak, że istnieją ważniejsze czynniki, które prowadzą do rozbieżności w niezawodności oprogramowania:

1. Abstrakcja związana z oprogramowaniem. Powoduje to, że twórcy oprogramowania źle rozumieją, jak rzeczy naprawdę działają. Z biegiem czasu dodaje się coraz więcej abstrakcji. Na przykład język asemblera daje bezpośrednią kontrolę nad maszyną. C jest bardziej abstrakcyjne, ale wciąż blisko maszyny. Java, C # i to, co będzie dalej, mocno abstrakuje to, co dzieje się w maszynie. Innym przykładem jest to, że jeśli jesteś programistą, który chce zrozumieć, w jaki sposób sieć działa na poziomie oprogramowania, powinieneś wiedzieć, jak programować w C, ponieważ infrastruktura (jako oprogramowanie) jest napisana w C.

2. Różne doświadczeniaa wiedza twórców prowadzi do różnych wyników. Różni programiści tworzą oprogramowanie o różnej niezawodności. To samo można powiedzieć o producentach samochodów. Różnica polega jednak na tym, że każdy, kto może korzystać z edytora i kompilatora, a nawet po prostu zainstalować IDE (zintegrowane środowisko programistyczne), może tworzyć oprogramowanie i za darmo. Aby zrobić samochód, potrzebujesz ogromnej inwestycji, fabryki (niektórzy mogą zrobić samochód bez użycia jednego, ale nie wszędzie go znajdziesz). Fakt, że włożysz ogromną inwestycję, oznacza, że ​​będziesz próbował zatrudnić najlepszych w tej dziedzinie. Nadal jednak występują problemy z niezawodnością samochodów. Jeśli zdajesz sobie z tego sprawę, wiele milionów samochodów jest wycofywanych z rynków z powodu poważnych [błędów]. W moim samochodzie producent zastąpi nożyce do hamulców bezpłatnie dla wszystkich samochodów kupionych w tym samym roku.

3. Błędy w oprogramowaniu są zwykle bardziej widoczne dla użytkowników niż samochody. Jest to wynik interakcji i reakcji między użytkownikiem a oprogramowaniem. W samochodzie zwracamy uwagę na mniejszą liczbę szczegółów, takich jak „Samochód przyspiesza, gdy naciskamy pedał gazu”, łamanie, skręcanie, światła, lusterka, itp. W oprogramowaniu, z każdym kliknięciem / wejściem użytkownika zwykle odpowiedź. Jest więc wiele punktów, w których oprogramowanie może być wadliwe, a użytkownik natychmiast to zauważy. To sprawia, że ​​użytkownik uważa, że ​​jest mniej niezawodny niż samochody.

4. Hakowanie i ataki . Im szerzej stosowane jest oprogramowanie, tym wyższy jest odsetek ataków hakerskich. Możesz to porównać do kradzieży samochodu. Dla mnie także niezawodność samochodu jest zagrożona, gdy może go otworzyć ktoś inny niż jego właściciel lub klucz. Jednak łatwiej jest zaatakować oprogramowanie niż samochód, ponieważ atakujący nie jest widoczny. Tak więc, gdy oprogramowanie jest zagrożone, ludzie kojarzą go z tym, że nie jest on niezawodny, nawet jeśli jest niezawodny w tym, do czego został stworzony.

Jest jak wszystko inne ... kiedy to działa, nie obchodzi cię to ... kiedy się zepsuło (lub nie działa tak, jak chcesz / oczekujesz) zależy.

Pomyśl o samolotach. Mnóstwo ludzi martwi się, że ludzie próbują je porwać lub wysadzić w powietrze. Ale tak naprawdę liczba negatywnych zdarzeń jest niewielka w porównaniu z liczbą codziennych lotów. (W ciągu jednego dnia jest więcej lotów, które zostały kiedykolwiek uprowadzone lub zbombardowane. Do cholery nawet próbowano porwać lub zbombardować.)

Wszystko zależy od tego, jak wyglądasz i jak mierzysz.

To jest właściwie dość proste. Samochody to stara technika. Na pewno tam wodotryski te dni (które rozkładają), ale jeśli spojrzeć na początku samochody - one złamał wiele .

„Technologia” mechanicznych części samochodów istnieje od setek lat, a silnik spalinowy również istnieje od dawna, a kiedy zostały wprowadzone, pojawiło się wiele problemów.

Weź pod uwagę, że problemy z pamięcią są już prawie przeszłością w przypadku niektórych naszych zarządzanych platform. Daj oprogramowanie na kilkaset lat, a my też go przybimy. Biorąc pod uwagę złożoność oprogramowania, wydaje mi się, że wyprzedzamy.

Nowoczesne samochody polegają na s / w. Kiedy zawodzą nowoczesne samochody, na przykład zawodzi komputer z silnikiem, zwykle (choć nie zawsze, ale zwykle) elektronika, a nie s / w.

Zapytaj każdego właściciela nowoczesnego samochodu z ECU, ile czasu przed jego kosztowną awarią. Będę oszołomiony, jeśli dostaniesz 10 lat. Nowoczesne samochody pełne elektroniki i czujników są zadziwiająco zawodne.

Jeśli przestudiujesz teorię niezawodności, odpowiedź stanie się zupełnie oczywista. Wszystko, co mechaniczne (oprogramowanie oczekuje), ma niezawodność w stanie ustalonym, czyli wskaźnik awaryjności poza obszarami śmiertelności niemowląt i ich zużycia. Współczynnik awaryjności elementu końcowego jest sumą wskaźników awaryjności części. Dodaj więcej części: łączna liczba awarii staje się większa. Wyzwanie polega zatem na tym, aby wskaźniki awarii wszystkich tych komponentów były naprawdę niskie.

Jeśli chodzi o rzeczy takie jak paski rozrządu i zużycie cylindrów i czujniki tlenu pełne bzdur, a złącza stają się oporne, a przewody pękają z powodu wibracji - istnieją techniki, które można zastosować w celu zmniejszenia wskaźnika awaryjności. Koszty również rosną, gdy to robisz.

Z drugiej strony oprogramowanie ma stały wskaźnik awaryjności. Pomimo trudności w znajdowaniu wad, czasami całe oprogramowanie jest maszyną do kiełbas. Wejścia -> Wykonaj czynności -> Wyjścia. Czasami ZAMÓWIENIE wejść i ich kombinacje prowadzą do awarii w wykrywalnych trybach. Kiedy to się stanie, znajdziesz wadę, naprawisz ją i idziesz dalej.

Oprogramowanie, które nie ma (znanych) defektów, ma współczynnik awaryjności równy 0. Będzie działać wiecznie bez awarii. (Średni czas między awariami = 1 / wskaźnik awaryjności). Platforma sprzętowa najpierw zawiedzie.

Oprogramowanie z defektami może działać tylko do momentu, gdy odpowiednia kombinacja warunków wejściowych z czasem spowoduje, że defekt pojawi się.

FALLACY w tym wszystkim polega na próbie porównania wskaźników awaryjności rzeczy fizycznych (spowodowanych zużyciem, migracją metali w układach scalonych, wnikaniem wody, wibracji itp.) Ze stopniem awaryjności tego, co jest zasadniczo maszyną o stanie skończonym, która po prostu robi dokładnie co nakazuje jej sekwencja instrukcji.

(Nawet rzeczy, takie jak cząstki alfa przerzucające bity w pamięci RAM, są zjawiskiem fizycznym, a nie defektem oprogramowania. Sposób obsługi takiej równomiernej MOŻE jednak być wadą oprogramowania, ale pamiętaj, że ta paskudna cząstka alfa była tylko kolejnym wejściem do oprogramowania. )

Różnica między oprogramowaniem a samochodami polega na tym, że aby programiści zachowali rozsądek, wszyscy użytkownicy oprogramowania muszą prowadzić dokładne duplikaty oprogramowania, a producenci samochodów, aby zachować rozsądek, muszą zaakceptować, że wszyscy ich użytkownicy będą prowadzić znacząco różne samochody, ponieważ sposób prowadzenia samochodu zmienia samochód, ale sposób korzystania z oprogramowania niekoniecznie zmienia oprogramowanie.

Z drugiej strony,

Gdybyś miał jakiś sposób na sprawdzenie oleju w swoim oprogramowaniu, wiedziałbyś, kiedy zawiedzie.

Gdybyś miał jakiś sposób na zmianę oleju w swoim oprogramowaniu, prawdopodobnie byłbyś w stanie przedłużyć jego żywotność o kilka miesięcy.

I bezsensownie rozszerzać analogię:

Łaty nie zmieniają oleju, zastępują nieszczelną uszczelkę.

Aktualizacje nie zmieniają oleju, naprawiają hamulce.

Wydania nie zmieniają oleju, są bardziej jak dodanie zapłonu bez kluczyka.

Samochody, które się psują, nie są tolerowane. Może także zagrażać życiu. Oprogramowanie, które ulega awarii, jest tolerowane, a użytkownicy obchodzą go lub akceptują. Nie ma dużego zapotrzebowania na oprogramowanie wolne od błędów.

Również oprogramowanie jest dostosowane, nie masz 10000000 różnych modeli samochodów. Powiedziałbym, że Wikimedia jest niezawodna i wiele osób korzysta z tego oprogramowania. Można więc powiedzieć, że wiele osób używa oprogramowania wolnego od błędów lub niezawodnego. (wordpress, różne sterowanie źródłami, mysql i sqlite są dość niezawodne itp.)

Oprogramowanie to obiekty matematyczne i logiczne, podczas gdy samochody są prawdziwymi obiektami.

Co więcej, możesz łatwo dowiedzieć się, kiedy samochód ma problem i jaki jest problem, podczas gdy oprogramowanie może być znacznie trudniejsze: wyobraź sobie, że ktoś ma problem z komputerem i ktoś ma problem z samochodem; ta osoba może lepiej wiedzieć, co jest nie tak, ponieważ samochody są mniej abstrakcyjne niż komputery.

Nie twierdzę, że komputery są trudniejsze do zrozumienia: samochody wiążą się również z wieloma prawami fizycznymi, takimi jak termodynamika, elektronika, chemia.

Możesz także ekstrapolować to porównanie, mówiąc: „dlaczego młot jest bardziej niezawodny niż sekretarka?”.

Nie sądzę, aby pytanie było naprawdę istotne, ale wydaje mi się, że pokazuje bardzo dobrze, jak brak dobrej edukacji matematycznej może wpłynąć na zrozumienie pewnego rodzaju systemu.

Oprogramowanie jest znacznie bardziej złożone niż samochód, nawet jeśli samochód składa się z tysięcy elementów.

Gdyby samochód był tak złożony jak oprogramowanie, wówczas wszystkie części składowe samochodu zależałyby od wszystkich pozostałych części składowych samochodu, a wiele części składowych samochodu byłoby bezpośrednio połączonych z wieloma innymi częściami składowymi samochodu.

Wszystkie samochody na świecie ledwo dorównują złożoności oryginalnemu oprogramowaniu Unix.