Perché il software non è affidabile come un'auto? [chiuso]

Ho avuto un utente mi ha fatto questa domanda. Sappiamo che le auto si rompono, ma è a causa di qualcosa di fisico (a meno che non sia coinvolto un software!).

Ho cercato di rispondere che il software è un settore molto più giovane, ma l'utente ha risposto "L'industria automobilistica non è diventata molto più stabile e affidabile con meno persone?".

Ho anche provato a rispondere che il software è più complesso, ma l'utente ha risposto che ci sono molte migliaia di parti che compongono un'auto. Le persone che progettano e costruiscono automobili generalmente conoscono molto bene i loro componenti, ma finiscono comunque per lavorare insieme come risultato finale.

Quindi, perché il software non è affidabile come un'auto?

La premessa della tua domanda è semplicemente errata: il software non è "meno affidabile" di un'auto. Esistono miliardi e miliardi di dispositivi che eseguono software embedded 24x7, per anni e anni, senza problemi. Diamine, alcuni di questi sono in auto e controllano / monitorano il motore. Quindi, come può il software essere meno affidabile di un'auto, se le auto stesse si affidano al software?

Progetto software e parti meccaniche.

È complessità.

Perché ci sono milioni di "parti" nel software moderno.

Le parti del software sono molto complicate e hanno molto STATO. Una parte meccanica non mobile non ha stato.

Una parte mobile meccanica ha la sua posizione (una variabile).

Un programma in esecuzione e utilizza 1 MB di RAM ha un milione di byte di stato. Questo è molto più stato di qualsiasi normale sistema meccanico.

Ci saranno combinazioni di stati che non vengono mai testati perché accadono così raramente. In un sistema meccanico (come un'auto) è facile controllare che le parti meccaniche non si tocchino durante il funzionamento. Il software CAD meccanico che utilizzo al lavoro lo fa automaticamente.

Se costruissi macchine da parti invisibili e non toccabili, e avessi milioni di parti in movimento che si mancavano tutte, sarebbe come un semplice programma.

Anche "ciao mondo" gira su un sistema operativo. I vecchi sistemi a 8 bit e i sistemi operativi dei minicomputer erano abbastanza affidabili perché erano semplici.

Cose come DLL e librerie condivise vengono sostituite come parte di aggiornamenti di virus o installazioni di software e quindi il programma di interesse non funziona. Un po 'come cambiare la gomma della tua auto per una bicicletta. Alcuni degli stati limite della funzione di libreria interferiscono (non agire come previsto dal programma).

I programmi scritti in linguaggi come Java che non consentono molte interazioni non progettate tra oggetti (riutilizzo dei puntatori, overflow dei limiti dell'array) sono generalmente abbastanza affidabili una volta che sono stati messi in funzione.
Quando si utilizzano sistemi operativi con librerie statiche, una volta che funziona un programma continua a funzionare (ma avrà comunque molte condizioni limite, in base alle dimensioni dello stato).

Dave Parnas scrive sull'affidabilità del software riducendo lo stato del programma. I rigidi programmatori funzionali stanno facendo la stessa cosa forzando un singolo compito statico.

È una questione di scelta del consumatore.

Se i consumatori chiedessero che il software sia affidabile quanto la mia Honda Civic (al contrario della mia vecchia Ford Maverick), lo sarebbe. Alcune organizzazioni richiedono un software così affidabile e lo ottengono, in genere per software incorporato, a volte per cose critiche per la sicurezza come le missioni spaziali e il controllo del traffico aereo. Il software non è ancora perfetto, ma nemmeno le auto.

Tuttavia, i clienti richiedono altre qualità nei loro software, e per lo più non sono disposti a pagare per software che è forse meno funzionale, sicuramente più costoso, e spedito in seguito solo perché è più affidabile.

ci sono molte migliaia di parti che compongono un'auto.

Se solo un computer (e il software associato) fosse così semplice.

Il computer ha un gigabyte di memoria? Miliardi di infradito? Un terabyte di disco? Trilioni di parti "mobili"?

Il software può avere 10 o migliaia o 100 di migliaia di singole righe di codice in esecuzione. Inoltre, molti (o più) test unitari e strumenti.

No. L'argomento "Anche le auto sono complesse" è a castello. Il software è molto, molto, molto più complesso di un'auto.

I principi che fanno funzionare i motori a combustione e tutti i componenti che compongono un'auto non sono cambiati molto nel secolo scorso. Certo ci sono stati miglioramenti evolutivi e auto ibride, ma i componenti di base sono gli stessi. Hai un motore, una trasmissione, ecc. Anche le concept car e la tua super costosa Bugatti Veyron sono costruite con la stessa struttura di base. In breve, progettare un'auto è un problema ben noto .

In contrasto con lo sviluppo di software.

• I clienti non sanno cosa vogliono quando iniziano. Cominciano a parlare di un jet di lusso, ma poi quando si rendono conto dei costi vogliono che tu lo costruisca per il costo di uno scooter a pedali.
• La progettazione automobilistica impiega anni per passare dall'idea alla concept car e altri anni per arrivare da lì alla produzione. Quando è stata l'ultima volta che hai avuto quel lusso con il software?
• Le parti di automobili sono pezzi di metallo fuso, ma i componenti software possono cambiare spesso forma e interfaccia.
• Il processo di fabbricazione è completamente diverso. Con le automobili, i pezzi vengono fabbricati in grandi quantità e gli stessi pezzi vengono utilizzati su veicoli diversi. Con il software quasi tutto è fatto a mano perché altrimenti le cose non vanno bene.

In breve, ci sono una serie di ragioni per cui un'auto sarebbe percepita come "più affidabile" del software. Ho appena avuto un paio.

Le auto sono affidabili. Lo stesso vale per la maggior parte dei software.

Ma ... le auto personalizzate e il software personalizzato hanno entrambi i loro problemi.

Qualsiasi vero appassionato di auto, che ha la sua muscle car modificata del 1970, armeggi e modifiche, e ha avarie e tutti i tipi di stupidi problemi che non avrebbe avuto se l'avesse lasciata originale. Ma ... allora non avrebbe avuto il compressore ...

Poiché l'auto che guidi è stata realizzata molte volte, il processo di costruzione è così raffinato che la stessa auto può essere realizzata su una linea di produzione più e più volte.

Se fosse un'auto complessa unica nel suo genere, costruita da zero una volta non sarebbe affatto affidabile, ad esempio guarda quanto è più elevato il tasso di fallimento nelle auto da corsa di formula 1. È comune che uno o due si rompano per gara.

Il nuovo software è sempre una tantum. Ciò che il codice dei programmatori non è mai stato codificato da loro prima. Ottenere una qualità davvero elevata in questo scenario comporta un costo proibitivo per la maggior parte dei prodotti. Ogni nuovo software non banale è effettivamente un prototipo.

A parte questo, questo è uno dei motivi principali per cui l'applicazione delle tecniche di ingegneria tradizionali all'ingegneria del software è un disastro.

1. I costruttori di automobili ottengono le specifiche complete prima di produrre il prodotto "finale".
2. Gli utenti di automobili non tendono a fare cose stupide che i progettisti non si aspettavano.
3. Le auto vengono "aggiornate" solo una volta all'anno (in genere), mentre la maggior parte dei software dovrebbe essere aggiornata più volte all'anno.

Potrei continuare, ma il mio browser sembra che stia per arrestarsi ...

C'è in realtà un motivo molto semplice.

Il software che fa soldi è un software che guadagna quote di mercato. Più spesso che no, l'azienda che porta un pezzo di software per il mercato prima sarà quella che ottiene la maggior parte della quota di mercato, anche se il loro software non è il miglior prodotto nella loro particolare mercato.

Di conseguenza, l'obiettivo è quello di ottenere il software rilasciato prima e imperfetto, piuttosto che dopo e perfetto.

Mi piace la maggior parte delle risposte finora. Ecco il mio giro su di esso.

Il costo per guasto è più grave per le auto rispetto al software

Il fallimento dell'auto potrebbe potenzialmente costare una vita. Anche un guasto al veicolo non pericoloso rappresenta un inconveniente altamente visibile per l'utente. Il fallimento del software significa solo che una povera linfa nel supporto alla produzione dovrà fare gli straordinari. E se quella persona è un dipendente esente a tempo pieno, allora accidenti, non è affatto costoso. In effetti, la scarsa qualità e la cattiva gestione vengono premiate perché gli straordinari gratuiti riducono effettivamente il costo del lavoro all'ora!

Naturalmente, questo dipende dal tipo di software utilizzato (il software che alimenta i sistemi d'arma, i sistemi avionici o medici potrebbe anche avere un effetto sulla vita), ma un'auto costa una buona quantità di denaro e viene utilizzata abbastanza regolarmente che i cali di affidabilità sono abbastanza tangibile e doloroso. Gli errori del software hanno spesso soluzioni alternative.

Un altro pensiero: le auto sembrano affidabili ma hanno costi di manutenzione definiti che sono in corso anche se l'auto funziona bene, e culturalmente, questo è accettato e persino una spesa orgogliosa da parte delle persone che si prendono cura dei loro veicoli. D'altra parte, il software è spesso già rotto quando installato e spesso deve cambiare nel tempo, ma culturalmente, nessuno vuole pagare per la manutenzione.

Bene, le auto erano piuttosto inaffidabili per gran parte della loro storia, e c'è sicuramente una curva di apprendimento. Le automobili sono state prodotte su larga scala per circa 60 anni, mentre il software è stato prodotto su larga scala per circa 20-25 anni. In larga scala, intendo fondamentalmente abbastanza grande che le masse lo acquistano / lo usano e c'è davvero un grande incentivo per capire come perfezionare la procedura per crearlo.

Mi piace pensare all'auto come a un'applicazione. Mentre il sistema operativo è la strada su cui viene eseguita l'applicazione.

L'interfaccia tra strada e auto è ben definita. Ben testato ed è ampiamente verificato per la compatibilità con le versioni precedenti (che è facile in quanto l'interfaccia è semplice). Ma anche così hai alcuni problemi di compatibilità con le versioni precedenti. Le auto di tipo "Farrie" fanno fatica a correre su strade di tipo "strade fangose".

Anche così il tuo sistema operativo, proprio come le strade, necessita di una manutenzione costante. Ponti fuori. Le automobili indossano catene da neve e lacerano le strade come un'applicazione corrotta e danneggiano i dischi e i file utilizzati dal sistema operativo.

Le domande saranno scritte su un sistema operativo. Ma in generale devono eseguire diverse versioni del sistema operativo (diversi tipi di strada). Pertanto, l'app ottimizzata per la cena potrebbe funzionare senza problemi e senza problemi purché venga eseguita sul sistema operativo corretto (autostrade), mentre altri codici generici (più semplici) funzioneranno bene su tutti i tipi di strada.

L'interfaccia tra applicazione e sistema operativo è definita ma estremamente complessa e sempre leggermente fluttuante. Soprattutto perché consentiamo all'utente di modificare il proprio sistema operativo con estensioni. Se il governo consentisse agli utenti di modificare le strade ci sarebbero molti più incidenti.

Quando si inizia a limitare la capacità dell'utente di modificare il sistema operativo, l'affidabilità delle applicazioni può diventare quasi solida. Guarda tutti quei dispositivi integrati. Non permettiamo agli utenti di avvicinarsi al proprio sistema operativo e di funzionare correttamente e continuamente 24 ore su 24, 7 giorni su 7, senza interruzione.

Quindi direi che non è quel software inaffidabile. È più come dire che gli utenti stanno scavando buche in autostrada per le applicazioni. Ehi, la tua domanda è appena caduta nel buco che ho scavato l'anno scorso e di cui mi sono dimenticato .

Innanzitutto, il tuo utente deve sapere che esiste un software così affidabile in questo mondo che non sa nemmeno che esiste. Hai mai visto un incidente TV? Neanche io.

Penso che il motivo principale sia che il software è irrilevante. Essere immateriali significa che i non sviluppatori non vedono i progressi in corso. Ad esempio, se stavo costruendo una macchina, potresti vedermi assemblare le diverse parti e sembrerebbe sempre più una macchina; tuttavia, se mi guardi programmare, forse passerò ore a imprecare contro uno schermo nero con il testo verde che fa strani schemi e poi improvvisamente quando lo schema cambia solo un po 'mi eccito.

Per questo motivo, le persone normali non comprendono la complessità del software. Quando vedono una finestra, pensano di vedere il programma nel suo insieme, il che è davvero così sbagliato.

Inoltre, il software è molto, molto più spesso fortemente personalizzato rispetto alle automobili. Quando personalizzi un'auto, non andrai contro il suo design perché sarebbe visibilmente stupido. Se il mio motore è nella parte anteriore della macchina, spostarlo verso la parte posteriore sarà molto probabilmente un enorme disastro. Tuttavia, poiché il software è irrilevante, se il client ti chiede di fare qualcosa di completamente contrario al design, non riceveranno alcuna indicazione (tranne te, ma non ascolteranno) che quello che stanno facendo è stupido, e poi ' Sarò sorpreso che non funzioni come previsto.

1. Mancanza di condivisione delle informazioni (i programmatori volano da soli o in piccoli gruppi - i progettisti di auto lavorano con team interconnessi all'interno di una grande azienda e condividono tutti le loro conoscenze; ​​se tutti lavorassimo per le grandi società, saremmo tutti programmatori migliori grazie all'apprendimento dagli altri; questo è anche il motivo per cui cose come programmi open source e risorse online sono molto importanti)
2. Aspettative dei concorrenti sul campo (va bene se un progettista di auto è solo marginalmente utile per i primi 5-10 anni, ma se un programmatore partecipa a un'intervista e dice che non sarà di grande utilità per 5-10 anni, il l'intervista è finita)
3. Test di mancanza di penetrazione (a causa della mancanza di fondi, problemi di legalità, ecc .; i produttori di auto, tuttavia, sbattono un'auto dopo l'altra in un muro di mattoni, hanno gallerie del vento, hanno requisiti di prestazione relativamente semplici, ecc.)
4. Trasparenza delle informazioni (non sai come funziona la maggior parte del software; indovina o fai ipotesi basate su interviste, comunicati stampa, pubblicità, ecc. Con le auto, tuttavia, la maggior parte delle cose è lì per te da guardare)
5. Inherent Encapsulation of Knowledge (il ragazzo / robot che salda insieme il telaio non ha bisogno di conoscere la matematica alla base del sistema di controllo della stabilità; i programmatori devono essere informati su migliaia o decine di migliaia di cose sconosciute alla persona media, mentre solo i progettisti di auto bisogno di sapere centinaia o migliaia)
6. Tangibilità (aiuta quando puoi vederlo)
7. Age of Field (il design del veicolo ha migliaia di anni; il design del veicolo motorizzato ha più di 250 anni [motori a vapore, ecc.])
8. Criticità dei sottosistemi (le auto continueranno a "funzionare" anche se molte delle loro parti smetteranno di funzionare: blocchi di potenza, alzacristalli elettrici, HVAC, tergicristalli, vetri rotti, coprimozzi persi, pneumatici piatti [inserirne uno nuovo], radio, una luce o due, voce remota, ecc .; quando qualcosa su un computer si rompe, è spesso uno scenario SHTF)
9. Interdipendenza (quando un computer si rompe, non è raro che colpisca centinaia o migliaia di altri computer; quando un'automobile si rompe, è alquanto raro che siano interessate altre auto - se altre auto sono interessate, è quasi sempre solo 1 -3)
10. Blanket Blame (se una parte di un computer o un computer su migliaia rompe e danneggia un sistema, la colpa si estende a tutto il computer o, in quest'ultimo caso, all'intera rete di computer; se la tua auto viene colpita da un'auto con freni falliti o se un'auto si ferma e non si riavvia in autostrada, viene biasimata solo la parte dell'auto individuale)
11. Sistemi finiti contro infiniti (le auto possono avere solo tanto impacchettato e si aspettano di lavorare solo in condizioni limitate, ad esempio non si guida una BMW su un terreno che solo un veicolo simile a una jeep può fare; con computer, tuttavia, le possibilità sono di fatto infinite: ci sono sempre nuove cose, nuove API, nuovi sistemi operativi, nuove falle di sicurezza, iPad, software per telefoni cellulari, novità, novità, ecc.)
12. Scopo del corpus necessario di conoscenza (una persona con un QI di 130-140 potrebbe imparare quasi tutto quello che c'è da sapere sulle auto, ma potrebbe imparare solo una piccola parte di ciò che c'è da sapere su computer e programmazione)

Il semplice motivo per cui l'intera logica è imperfetta:

I dispositivi meccanici possono essere semplicemente ridotti a Input / Output ; l'aumento del numero di parti per ottenere questa operazione I / O non modifica l'operazione I / O. Pertanto, il sistema può essere pienamente compreso.

Il software d'altra parte ha Input -> Process -> Output . Per questa natura il sistema non può essere completamente previsto o compreso.

Donald Rumsfeld l'ha detto meglio:

“Ci sono noti noti; ci sono cose che sappiamo di sapere. Sappiamo anche che ci sono sconosciuti noti; vale a dire sappiamo che ci sono alcune cose che non sappiamo. Ma ci sono anche incognite sconosciute - quelle che non sappiamo non lo sappiamo. "- Il segretario alla Difesa degli Stati Uniti Donald Rumsfeld

In sintesi:

• Un dispositivo meccanico è un sistema che ha conosciuto e conosciuto-sconosciuto,
• Il software ha quanto sopra ma anche sconosciuti-sconosciuti.

Questa è una domanda stupida (non da te, ma dalla persona originale).

Sembra mio padre (un meccanico) che odia i computer e trascorre tutto il giorno su eBay.

È come chiedere "Perché un albero è più affidabile di una falena?".

Prima di tutto, possiedo 30 (sì, 30+) computer e nessuno di loro è stato nel negozio. Ho appena speso $ 1400 per la mia auto nelle riparazioni. Vai a contare il numero di negozi di riparazioni auto vs riparazione computer Ancora una volta, stupida analogia.

Le auto sono realizzate in acciaio, i computer in plastica. Le auto funzionano in tutte le condizioni atmosferiche, computer progettati per uso interno.

Il mio Commodore 64 (26 anni) funziona perfettamente e non ha avuto riparazioni. Entrambi i miei veicoli (meno di 10 anni) hanno subito riparazioni molto estese. Fammi vedere un'auto con migliaia e migliaia di ore di utilizzo che ha 26 anni e funziona ancora al 100% come quando era nuova di fabbrica.

Il software si basa sui bit: 0 e 1. Le automobili sono basate (principalmente) su parti meccaniche.

Una parte meccanica può usurarsi o non funzionare correttamente e comunque tipo di lavoro. I freni si consumano o una valvola perde, ma l'auto funziona ancora fino a quando non è possibile ripararla.

Il software, per la maggior parte, non ha problemi graduali. Funziona o si rompe. La divisione per zero non è "quasi corretta"; è solo un errore. Quando si tenta di salvare su un'unità senza spazio sufficiente, non è possibile spremere forte per forzare tutti i dati; semplicemente non andrà.

Non penso che il software sia necessariamente meno affidabile di un'auto, ma quando il software fallisce, fallisce immediatamente, non gradualmente.

Penso di avere un'analogia molto migliore. Prendi un'azienda che costruisce ambulanze su specifica del cliente. La piattaforma di base (per esempio, un telaio completamente operativo e legale per strade scoperte) richiede modifiche in diversi punti: telaio, sistema di ricarica, beccuccio di riempimento, sospensioni, ecc. soddisfacendo i desideri dei clienti.

Quindi devi costruire il corpo dell'ambulanza stesso, che è anche pieno di requisiti normativi da diversi strati di governo e altri organismi. Pur soddisfacendo al contempo il desiderio del cliente per una disposizione dei posti a sedere funky o un sistema di archiviazione. E non dimenticare che hai un centinaio di clienti diversi da tutto il mondo su diversi piani di acquisto e distribuzione, nessuno dei quali dice mai "Ne prenderò una dozzina in più come l'ultimo" senza inviare anche pagine di eccezioni che spesso richiedono una reingegnerizzazione completa del tutto.

Automobili? È banale. Acquisterai ciò che è costruito e non avrai alcun impatto diretto su qualsiasi aspetto del design. Anche la tua scelta del colore è artificiale perché in realtà non puoi specificare qualcosa che non sia già stato progettato e testato. C'è in un certo senso solo un "mercato", non un "cliente". Direi che i software standardizzati prodotti per alcuni mercati sono generalmente affidabili quanto l'auto che ritiri presso la concessionaria locale.

Le auto in realtà non sono affidabili come pensi. È solo che i guasti possono rimanere nascosti per lungo tempo (o ignorati) senza causare il fallimento dell'intera cosa. La tua auto perde olio e / o liquido di raffreddamento? No? Sei sicuro? Probabilmente ti sbagli ... Probabilmente sta perdendo una piccola quantità da qualche parte che non hai ancora notato ... Ora estendilo alla sospensione, ai pannelli della carrozzeria, agli interni, ecc. Non penso di aver mai ma ho incontrato un'auto con la quale non sono riuscito a trovare qualcosa di sbagliato. Tuttavia, la stragrande maggioranza delle parti è superflua per la missione del trasporto. Non così con un computer. Quasi ogni parte di un computer è fondamentale.

È il vecchio dibattito analogico vs digitale, appena riconfezionato. La TV digitale è fantastica, purché tutto sia perfetto. Nell'istante in cui qualcosa va storto, l'audio balbetta e il video si blocca rendendolo inutile. Confronta con la TV analogica dove potresti solo sentire un piccolo sibilo o statico che può essere facilmente ignorato.

In primo luogo, naturalmente, alcuni sw sono perfettamente affidabili e le auto - specialmente quelle britanniche e italiane - non sono necessariamente così affidabili.

Detto questo, la mia esperienza di lavoro con il software automobilistico è dovuta a due cose:

• Costi di garanzia. Quando il tuo sw fallisce, lo riavvii. Forse presenterai una segnalazione di bug. Oppure usa il costoso contratto di assistenza. Quando la tua auto si guasta, la porterai e chiederai che sia riparata in garanzia. Questo costerà al produttore $ 100 e oltre. Se ogni errore di sw costa al produttore $ 2, sono certo che sw sarebbe più affidabile.

• JD Powers (e altre classifiche di qualità). JD Powers esamina ThingsGoneWrong (che potrebbe essere qualsiasi cosa). E se quella classifica è davvero cattiva, le persone semplicemente non compreranno la tua auto, almeno non per abbastanza soldi per realizzare un profitto. Se avessimo un JD Powers per sw e la gente se ne preoccupasse davvero, allora sono abbastanza sicuro che sw sarebbe più affidabile.

Quindi, se costruisci auto inaffidabili, i costi di garanzia consumeranno rapidamente tutto il tuo profitto e in pochi anni classifiche di cattiva qualità significheranno che non venderai affatto auto. Se effettui sw inaffidabili, gli utenti si lamentano e puoi vendere costosi contratti di supporto.

L'affidabilità e la sicurezza dei veicoli a motore sono obbligatorie. In molti (la maggior parte?) Paesi è richiesto per legge che abbiano un livello minimo di affidabilità e sicurezza e che siano testati per lo scenario peggiore (qualunque cosa sia). Il software commerciale non lo è, per la maggior parte.

Mentre ci sono altre implicazioni legali per il software, è importante notare che se il software si arresta in modo anomalo ogni volta che si preme il pulsante "Salva", si tratta semplicemente di una patch / correzione e si continua. Se un'auto si blocca ogni volta che si accende l'indicatore, questa è una cosa molto peggiore . Semplicemente non è così importante per Microsoft Outlook funzionare senza crash inaspettatamente come lo è per un SUV da eseguire senza crash inaspettatamente.

Detto questo, ci sono altri software che hanno la stessa o più responsabilità della meccanica di un'auto. Gli aerei e i sistemi di guida missilistica devono essere affidabili; ci sono vite in gioco! Si spera che questi siano testati più rigorosamente rispetto all'automobile media.

L'industria automobilistica non rilascia un'auto "beta" al pubblico per i test, l'industria automobilistica non deve preoccuparsi dell'ambiente in cui consegnano i loro prodotti, tuttavia devo preoccuparmi di molte altre cose. dire che l'industria del software è inizialmente sostanzialmente diversa (come tutti sappiamo), quindi affidabilità e complessità sono davvero suggestive. Secondo me un'auto complessa rispetto a un software ma è più facile vedere cosa funziona o meno da allora

• Nella parte inferiore delle auto non sono virtuali, è destinato a essere più facile da testare (ma più costoso)
• Hanno iniziato molto prima del settore del software, anche se erano meno persone, non è possibile ridurre al minimo la pratica e le conoscenze acquisite. L'industria del software è ancora un bambino rispetto ad esso.
• Tutta l'industria automobilistica è vincolata dalla legge e dall'etica a non fare auto che uccide il suo guidatore, specialmente negli ultimi decenni.

Quindi l'affermazione secondo cui il software è meno affidabile delle auto, può essere vera per molti tipi di software e completamente sbagliata per altre aree (sicurezza, aeronautica ...) puoi essere sicuro che un software sia almeno il più affidabile del più affidabile di macchine in quella zona. Semplicemente perché quelle aree sono critiche e da quello che so solo in quelle aree il software può essere paragonato all'industria automobilistica.

Il che ci porta a questo: la maggior parte dei software non è considerata critica nel loro dominio. Se considerato come tale, disponi di un software affidabile, l'unico problema che troverai su questi sono problemi legati all'ambiente (quindi se puoi controllarlo, praticamente non avrai problemi), non il software stesso. Tuttavia, la maggior parte dell'editor di software non funziona in queste aree critiche, ovviamente sono tenuti a fornire un certo livello di qualità, ma sono più tenuti (a mio avviso) a consegnare il software il prima possibile. Tuttavia, un buon software richiede: buona gestione del progetto, specifiche solide, buona progettazione e buon livello di competenze da parte di coloro che vi lavorano (per riprenderlo). Questo è solo per farlo, non stiamo nemmeno parlando di venderlo ...

Tutto ciò richiede tempo e quindi richiede denaro. Non sto dicendo che ottieni quello che stai pagando per quello che sto dicendo la maggior parte delle volte produci ciò per cui non investi mai meno (tranne se sei stato fregato ma poi non produci nulla così ...) e qualche volta di più. .

Non credo che le auto siano meno complesse. Ma anche in questo caso, non credo che il software sia meno affidabile. Tuttavia, credo che ci siano fattori più importanti che portano a discrepanze nell'affidabilità del software:

1. Astrazione coinvolta nel software. Questo fa sì che i creatori di software non capiscano come funzionano veramente le cose. Col passare del tempo, viene aggiunta sempre più astrazione. Ad esempio, il linguaggio Assembly consente di controllare direttamente la macchina. C è più astratto ma ancora vicino alla macchina. Java, C # e ciò che verrà dopo stanno fortemente astrattando ciò che accade nella macchina. Un altro esempio è se sei un programmatore che vuole capire come avviene la rete a livello di software, quindi dovresti sapere di programmare con C perché l'infrastruttura (come software) è scritta in C.

2. Esperienze diversee La conoscenza dei produttori porta a risultati diversi. Diversi sviluppatori creano software con diversa affidabilità. Lo stesso si può dire dei produttori di automobili. Tuttavia, la differenza è che chiunque può usare un editor e un compilatore o anche semplicemente installare un IDE (Integrated Development Environment) può creare software e gratuitamente. Per fare una macchina, hai bisogno di un enorme investimento, una fabbrica (alcuni possono fare una macchina senza usarne una ma non la troverai dappertutto). Il fatto che investirai enormemente significa che proverai ad assumere i migliori sul campo. Tuttavia, ci sono ancora problemi di affidabilità con le auto. Se ne sei a conoscenza, molti milioni di auto vengono ritirate dai mercati per gravi [bug]. Nella mia auto, il produttore sostituirà le pinze dei freni gratuitamente per tutte le auto acquistate nello stesso anno.

3. I bug nel software di solito appaiono più agli utenti che alle automobili. Questo è il risultato dell'interattività e della risposta tra l'utente e il software. In un'auto, prestiamo attenzione a un minor numero di dettagli come "L'auto sta accelerando quando premiamo il pedale del gas", si rompe, gira, luci, specchi, ecc. Nel software, con ogni clic / input di ogni utente di solito c'è una risposta. Quindi, ci sono molti punti in cui il software può essere difettoso e l'utente lo noterà immediatamente. Questo fa credere all'utente che sia meno affidabile delle auto.

4. Hacking e attacchi . Più è ampiamente utilizzato un software, maggiore è la percentuale che sarà sotto attacchi di hacking. Puoi confrontarlo con il furto d'auto. Anche per me l'affidabilità di un'auto è compromessa quando può essere aperta da qualcuno diverso dal proprietario o dalla chiave. Tuttavia, è più facile provare ad attaccare il software di un'auto poiché l'attaccante non è visibile. Quindi, quando un software è compromesso, le persone associano che non è affidabile anche se è affidabile per quello per cui è stato creato.

È come tutto il resto ... quando funziona non ti interessa ... quando è rotto (o non funziona nel modo che desideri / ti aspetti) ti interessa.

Pensa agli aeroplani. Tonnellate di persone sono preoccupate per le persone che cercano di dirottarle o farle saltare in aria. Ma in realtà il numero di eventi negativi è minuscolo rispetto al numero di voli giornalieri. (Ci sono più voli in un giorno che non siano mai stati dirottati o bombardati ... diamine, anche tentato di essere dirottato o bombardato.)

È tutto dentro dove guardi e come misuri.

In realtà è abbastanza semplice. Le auto sono vecchie tecnologie. Sicuramente ci sono campane e fischietti in questi giorni (quella pausa) ma se guardi le prime macchine - si sono rotti molto .

La "tecnologia" alla base delle parti meccaniche delle automobili è in circolazione da centinaia di anni e anche il motore a combustione interna è in circolazione da molto tempo, e quando sono stati introdotti, c'erano molti problemi.

Considera che i problemi di memoria sono quasi un ricordo del passato con alcune delle nostre piattaforme gestite. Dai al software un paio di centinaia di anni e lo faremo anche inchiodato. In effetti, considerando la complessità del software, penso che siamo in anticipo sulla curva.

Le auto moderne si affidano a s / w. Quando le auto moderne falliscono, ad esempio il computer del motore si guasta, di solito (anche se non sempre, ma di solito) l'elettronica che lo ha caricato, non la s / w.

Chiedi a qualsiasi proprietario di un'auto moderna con una ECU in essa quanto tempo dura prima di un guasto costoso. Sarò sbalordito se avrai 10 anni. Le auto moderne piene di elettronica e sensori sono incredibilmente inaffidabili.

Se studi la teoria dell'affidabilità la risposta diventa accecantemente ovvia. Tutto ciò che è meccanico (si aspettano software) ha un'affidabilità allo stato stazionario, che è il tasso di fallimento al di fuori delle regioni di mortalità infantile e di usura. La percentuale di guasti dell'articolo finale è la SOMMA delle percentuali di guasto delle parti. Aggiungi più parti: il tasso di errore aggregato diventa un numero più alto. La sfida quindi è quella di ottenere tassi di guasto di tutti questi componenti davvero bassi.

Quando si tratta di cose come cinghie dentate e usura dei cilindri e sensori di ossigeno che si riempiono di schifezze e connettori che diventano ohmici e cavi rotti a causa delle vibrazioni, ci sono tecniche che possono essere utilizzate per ridurre il tasso di guasto. Il costo aumenta anche mentre lo fai.

Il software, d'altra parte, ha un tasso di fallimento costante. Nonostante la difficoltà a trovare difetti a volte, alla fine tutto il software è una macchina per insaccare. Ingressi -> Fai cose -> Uscite. A volte l'ORDINE degli ingressi e le combinazioni di ingressi portano a guasti con modalità rilevabili. Quando ciò accade, hai trovato il tuo difetto, lo risolvi e vai avanti.

Il software che non presenta difetti (noti) ha effettivamente un tasso di errore pari a 0. Funzionerà per sempre senza errori. (Tempo medio tra guasti = 1 / tasso di guasto). La piattaforma hardware non funzionerà per prima.

Il software con difetti può funzionare solo fino a quando la giusta combinazione di condizioni di input, nel tempo, non si manifesta.

La FALLACY in tutto questo è di provare a confrontare i tassi di fallimento di cose fisiche (causati da usura, migrazione dei metalli nei circuiti integrati, ingresso di acqua, vibrazioni, ecc.) Con un tasso di fallimento di ciò che è essenzialmente una macchina a stati finiti che semplicemente fa esattamente ciò che la sequenza di istruzioni gli dice di fare.

(Anche cose come le particelle alfa che lanciano bit nella RAM sono un fenomeno fisico, non un difetto del software. Il modo di gestire un MAGGIO così regolare può tuttavia essere un difetto del software, ma ricorda che la brutta particella alfa era solo un altro input per il software. )

La differenza tra software e automobili è che affinché gli sviluppatori di software mantengano la sanità mentale, i duplicati esatti del software devono essere guidati da tutti gli utenti del software e affinché i produttori di automobili mantengano la sanità mentale, devono accettare che tutti i loro utenti guideranno auto significativamente diverse perché il modo in cui guidi un'auto cambia l'auto, ma il modo in cui usi il software non cambia necessariamente il software.

D'altro canto,

Se avessi un modo per controllare l'olio nel tuo software, sapresti quando fallirà.

Se avessi un modo per cambiare l'olio nel tuo software, probabilmente saresti in grado di prolungarne la durata di alcuni mesi.

E per estendere inutilmente l'analogia:

Le patch non cambiano l'olio, stanno sostituendo una guarnizione che perde.

Gli aggiornamenti non cambiano l'olio, stanno riparando i freni.

Le uscite non cambiano l'olio, sono più come aggiungere un'accensione senza chiave.

Le auto che si rompono non sono tollerabili. Inoltre può mettere in pericolo la vita. I software che presentano guasti sono tollerati e gli utenti lo aggirano o lo accettano. Non c'è molta richiesta di software privo di bug.

Anche il software tende ad essere personalizzato, non hai 10000000 diversi modelli di auto. Direi che Wikimedia è affidabile e tonnellate di ppl usano quel software. Quindi potresti dire che molte persone usano software affidabile o privo di bug. (wordpress, vari controlli del codice sorgente, mysql e sqlite sono abbastanza affidabili, ecc.)

I software sono oggetti matematici e logici, mentre le automobili sono oggetti reali.

Inoltre, puoi facilmente sapere quando un'auto ha un problema e qual è il problema, mentre può essere molto più difficile con i software: immagina qualcuno che ha un problema con un computer e qualcuno che ha un problema con un'auto; questa persona può sapere meglio cosa c'è che non va perché le auto sono meno astratte dei computer.

Non sto dicendo che i computer siano più difficili da capire: le automobili implicano anche molte leggi fisiche come termodinamica, elettronica, chimica.

Potresti anche estrapolare questo confronto, dicendo: "perché un martello è più affidabile di un segretario?".

Non penso che la domanda sia veramente pertinente, ma penso che mostri davvero bene come la mancanza di una buona educazione matematica possa influenzare la comprensione di un certo tipo di sistema.

Il software è molto più complesso di un'auto, anche se l'auto è composta da migliaia di componenti.

Se un'auto fosse complessa come un software, allora tutti i componenti dell'auto dipenderebbero da tutti gli altri componenti dell'auto e molti componenti dell'auto sarebbero collegati direttamente con molti altri componenti dell'auto.

Tutte le auto del mondo equivalgono a malapena alla complessità del software originale Unix.