Perché il settore IT non è in grado di fornire rapidamente progetti grandi e senza errori come in altri settori?

Marcia della morte di Ed Yourdon tocca un numero di queste domande di tipo meta.

In generale, l'industria del software non ha molte delle caratteristiche seguenti, che interferiscono con i progetti di grandi dimensioni.

• Standardizzazione e suddivisione degli elementi di lavoro.

  • Questo è certamente migliorato, ma i costrutti del design non sono ancora lì per rompere un grande sistema. In un certo senso, il software non può nemmeno essere d'accordo su cosa sia necessario per un determinato progetto, e ancor meno in grado di suddividerlo in componenti.
  • Aerospaziale, costruzione di edifici, auto, ecc. hanno tutte un'architettura molto basata sui componenti con interfacce ragionevolmente compatte per consentire uno sviluppo completamente parallelo. Il software consente ancora un eccessivo sanguinamento nelle aree corrispondenti.

• Un grande numero di progetti simili e di successo. L'A380 non era il primo grande aeroplano che è stato costruito Airbus . Esistono molte applicazioni software di grandi dimensioni, ma molte di esse hanno sofferto in modo drammatico in un aspetto o nell'altro e non si sarebbero avvicinate ad essere definite "riuscite".

• Un grande numero di designer e costruttori che hanno lavorato a numerosi progetti simili e di successo. Relativo al problema del progetto di successo, non avendo il talento umano che è stato lì, fatto che rende le cose molto difficili da un punto di vista della ripetibilità.

• "Mai" costruisce la stessa cosa due volte. In molti modi, un aereo è come qualsiasi altro aeroplano. Ha ali, motori, sedili, ecc. Grandi progetti software raramente si ripetono. Ogni kernel del sistema operativo è significativamente diverso. Guarda la disparità nei file system. E per quanto riguarda quanti sistemi operativi davvero unici ci sono? I grandi diventano cloni di un oggetto base a un certo punto. AIX , Solaris , HP-UX , ... torna a AT&T System V . Windows ha avuto un'incredibile quantità di trascinamento in avanti attraverso ogni iterazione. Le varianti di Linux in genere tornano tutte allo stesso core che Linus ha iniziato. Ne parlo, perché le varianti tendono a propagarsi più velocemente dei veri e propri sistemi operativi proprietari.

• Stima del progetto davvero pessima. Dal momento che il fattore di ripetibilità è così basso, è difficile proiettare quanto sarà grande e quanto tempo ci vorrà per costruire. Dato che i project manager e il Management non possono mettere le mani sul codice e vedere effettivamente ciò che viene fatto, vengono generate aspettative non realistiche riguardo le timeline.

• QA / QC non è enfatizzato tanto quanto potrebbe o dovrebbe essere per progetti più grandi. Ciò torna ad avere interfacce più libere tra i componenti e non presenta rigide specifiche su come i componenti dovrebbero funzionare. Quella scioltezza consente conseguenze indesiderate e insinuarsi negli errori.

• Qualifiche coerentemente misurabili. Generalmente, le persone parlano del numero di anni in cui hanno lavorato in lingua X o in programmazione. Il tempo trascorso viene utilizzato come sostituto del calibro o della qualità delle abilità. Come è stato detto molte volte prima, intervistare e trovare buoni talenti di programmazione è difficile. Parte del problema è che la definizione di "buono" rimane molto soggettiva.

Non intendo essere del tutto negativo, e penso che l'industria del software abbia fatto progressi significativi da dove siamo stati. Forum come questo e altri hanno davvero contribuito a promuovere la conversazione e la discussione sui principi del design. Ci sono organizzazioni che lavorano per standardizzare la conoscenza "di base" per gli ingegneri del software. C'è sicuramente spazio per miglioramenti, ma penso che il settore abbia fatto molta strada in un periodo di tempo ragionevolmente breve.

La risposta è sorprendentemente semplice: quelle "altre industrie" do hanno un alto tasso di insuccesso. Stiamo solo confrontando le cose sbagliate. Il software di scrittura è spesso chiamato "build", quindi lo confrontiamo con le fasi di produzione o costruzione in altri settori. Ma se la guardi, non è affatto costruzione: è design . I progetti software sono scritti in codice e la costruzione viene eseguita dai computer, sia compilando il software che interpretandolo direttamente al volo.

Molti progetti in altri settori richiedono più tempo di quanto stimato in origine, costano di più, o semplicemente non vedono mai il completamento. Ti sembra familiare?

Quindi, cosa stiamo facendo quando pianifichiamo il software? Bene, stiamo ancora progettando, ma in una fase precedente.

Nel software, non c'è una linea di produzione nota. Costruire il componente finale è (relativamente) economico, e la replica di quel prodotto finale è sia perfetta che efficacemente gratuita - copi gli artefatti di costruzione.

Per evidenziare alcune figure:

1. Modifica dei requisiti dopo l'avvio dell'applicazione ; per esempio, quando il primo Airbus A380 ha iniziato a essere creato in fabbrica, non posso credere che se qualcuno volesse 200 posti in più, questi sarebbero messi lì; ma in un grande progetto software, anche dopo che i programmatori hanno iniziato lo sviluppo, è possibile aggiungere altri 5 tipi di utenti.
2. Complessità - i progetti software di grandi dimensioni sono estremamente complessi; probabilmente i progetti più complessi progettati e sviluppati dal genere umano;
3. Non vengono spese abbastanza risorse nella fase di progettazione e architettura ;
4. L'immaturità del campo - l'ingegneria del software è relativamente una disciplina giovane rispetto con altre sorelle ingegneristiche; questo ha due implicazioni: a) Non così tante euristiche e buone pratiche; b) Non molti specialisti di grande esperienza;
5. Mancanza di prove matematiche - nella maggior parte dei casi i metodi matematici formali non sono usati per dimostrare che un pezzo di software funziona come richiesto; invece viene usato il test. Questo è vero in altri campi ingegneristici che si basano maggiormente sulla matematica; la ragione di questo è la complessità;
6. Rush - molti manager hanno scadenze irraggiungibili; quindi la qualità del codice è al secondo posto, a causa della scadenza.

Rispondendo rigorosamente alla domanda - Tendo a credere che gli altri abbiano aspettative molto alte (specialmente nei tempi di consegna) dei programmatori e non capiscano esattamente quanto sia difficile programmare un software di grandi dimensioni.

La premessa della domanda è un po 'imperfetta. Sia l'A380 che il Boeing 787 sono stati consegnati con un ritardo di alcuni anni.

Nel caso dell'A380, gran parte del ritardo è stato causato dalle unità francesi e tedesche di Airbus che utilizzano diverse e leggermente incompatibili versioni del software di progettazione CATIA . Questo si è manifestato in modo incompatibile come cablaggi che non si adattavano perfettamente all'aereo.

Non c'era niente di sbagliato in CATIA, che è il software di progettazione aeronautica più utilizzato, ma qualcuno da qualche parte ha abbandonato la sfera di configurazione del software.

Anche il Boeing 787 ha sofferto di ritardi legati al software, ma la maggior parte dei suoi problemi sono stati i tradizionali problemi dei nuovi aeroplani, come il controllo del peso e la consegna di parti sotto la norma da parte dei fornitori.

Sia l'A380 che il B787 hanno dovuto modificare i loro design delle ali dopo che l'aeromobile iniziale aveva problemi strutturali.

I progetti di grandi dimensioni sono difficili per l'uomo in tutti i campi.

Ragazzo del grattacielo qui. Non sono sicuro di poter rispondere alla tua domanda, ma posso sicuramente fare luce su vari elementi della discussione. Gli edifici si verificano davvero molto velocemente. Un vincolo importante è locale (regolamenti). Ma in generale ci vogliono da 3 a 10 anni per un edificio alto dall'inizio alla fine.

Penso che confrontare un nuovo edificio con un nuovo progetto software non sia molto accurato. Un nuovo edificio è più vicino a una nuova versione di un kernel o di un sistema operativo. In questo senso lo sviluppo del software è molto più veloce. Non abbiamo mai costruito da zero in quanto questo sarà un compito ad alto rischio che il cliente non vorrebbe mai sottoscrivere. La maggior parte della progettazione e dello sviluppo negli edifici è derivata da progetti collaudati e completati.

Dall'esperienza personale, solo un progetto su dieci viene costruito. Il processo è guidato dallo sviluppo piuttosto che dal design, quindi il momento in cui qualcosa come il prezzo dell'acciaio sale l'intero progetto è fuori dalla finestra, o progettato, poiché il design è il componente economico del processo.

Il design impiega un mese per schematizzare il concetto, da due a sei mesi per progettare lo sviluppo, altri sei mesi per i dettagli e i documenti di costruzione di un team di architetti, consulenti di pianificazione, ingegneri strutturali, ingegneri del vento, ingegneri dei servizi, consulenti di quantità e costi , topografi, ingegneri di accessibilità e la lista continua ...

L'argomento del virtuale rispetto al fisico non è molto accurato. Lavoriamo anche principalmente con strumenti virtuali e, inoltre, siamo remoti nel tempo e in scala dal nostro prodotto finale. Nella maggior parte dei casi non possiamo nemmeno testare gli aspetti degli edifici in scala di modelli e utilizziamo la simulazione per cercare di prevedere cosa potrebbe accadere.

Per quanto riguarda la complessità ci sono delle differenze, ma nel complesso è forse più o meno la stessa. Non abbiamo solo unità interconnesse e livelli multipli di astrazioni e interfacce a livelli, ma anche le persone sono molto specializzate in piccole parti del processo che rendono la comunicazione molto difficile.

Per quanto riguarda l'argomento del design rispetto allo sviluppo, penso che entrambi i processi siano progettati. Sembra accademicamente bello tenere questi separati, ma non è possibile progettare se non sai come funzionano le cose. Aumenta il rischio di fallimento.

Nel complesso, la mia stima (potenzialmente errata) secondo la domanda dell'OP è che la programmazione è più un'arte che ingegneristica. Perché le persone dovrebbero piacere e anche farlo gratis, trovare espressione ed eleganza in esso? L'informatica è anche (più sullo stagno) più di una scienza che di ingegneria. Perché dovresti provare a provare gli algoritmi invece di applicare le parti esistenti e lavorare per far funzionare le cose? Non sono sicuro che questo abbia senso; Non sono un ragazzo del software.

Un aspetto che mi colpisce della progettazione e dello sviluppo del software riguarda il mezzo stesso. I computer rendono il lavoro umano-incentrato molto innaturale. Tutto è così esplicito e ci sono poche tolleranze. È difficile orientarsi mentalmente intorno a questo, e alcuni lo fanno franca scaricando la complessità all'interno. Se non altro potrebbe avere qualcosa a che fare con questo?

Allora quanto tempo ha preso il design di quelli? Anno? Due? Dieci anni? Il design è la parte più complessa della costruzione di qualcosa, la costruzione stessa è facile.

Basato su questo articolo , viene lentamente compreso che lo sviluppo del software è principalmente un processo di progettazione in cui il documento di progettazione è il codice sorgente stesso. E il processo di progettazione è completamente diverso dal processo di produzione. Richiede persone esperte ed è impossibile pianificare, perché anche piccole modifiche ai requisiti possono comportare enormi cambiamenti nell'architettura generale del progetto. Questa comprensione è alla base delle metodologie agili che si concentrano sul miglioramento della qualità del codice come documento di progettazione finale e sull'esecuzione di test e debug come parti del processo di progettazione, proprio come testano i modelli di aerei nelle gallerie del vento.

La costruzione stessa viene gestita automaticamente dai compilatori. E grazie a questo, siamo in grado di costruire interi prodotti in pochi minuti.

Il motivo per cui i progetti software sono terminati con enormi ritardi e costi eccessivi è perché i gestori pensano ancora di poter stimare, prevedere e pianificare un tale processo di progettazione. Questo si ritorce più spesso di quanto sia effettivamente valido. Pensano ancora che legando le persone a un rigido processo di costruzione possono in qualche modo aumentare la qualità, anche se il risultato finale è in gran parte opposto con l'aumento dei costi e le scadenze impreviste.

Immagina, nel bel mezzo del progetto dell'Airbus A380, qualcuno abbia partecipato a una riunione e ha detto: "Heh, potrebbe costruirlo come un triplano?" Altri si sono uniti dicendo "Sì, sì. Un triplane, più ali sono migliori". I prossimi anni trascorsi a trasformare il design dell'A380 in un triplane. In un altro incontro, qualcuno dice: "Un triplane? È vecchio, vogliamo un biplano, basta rimuovere una delle ali".

O immaginate, nel bel mezzo di un progetto di costruzione di un ponte, qualcuno dice: "Heh, abbiamo appena stipulato un accordo con una compagnia di spedizioni, che ha bisogno di un ponte più alto di 40 piedi, perché le loro navi sono molto più alte. Grazie. "

Questi sono solo alcuni dei motivi per cui i progetti software, grandi e piccoli, finiscono in caso di insuccesso a un ritmo allarmante.

Come qualcuno con un background di ingegneria meccanica che lavora nel settore IT, mi sono spesso chiesto quali siano le ragioni del basso tasso di successo nell'IT.

Come altri in questa discussione, ho anche spesso attribuito i fallimenti all'immaturità dell'IT, la mancanza di standard dettagliati (sì, sono serio, hai mai controllato il foglio standard di un semplice fulmine?) e il mancanza di componenti e moduli standardizzati.

Anche altri settori, come la costruzione di edifici o la costruzione di navi, hanno molti più "sentieri battuti": conoscenza ed esperienza di un particolare prototipo di soluzione che, in forma personalizzata, viene riutilizzato più e più volte. Vi siete mai chiesti perché edifici, navi o aeroplani di dimensioni e scopi diversi in qualche modo sembrano così simili? (ci sono eccezioni alla regola ovviamente ...)

Questo perché quei prototipi sono ben studiati, ben compresi, generalmente utilizzati e hanno una comprovata esperienza. Non perché non potesse essere fatto in altro modo. Nella standardizzazione IT è raramente il caso: (grandi) i progetti tendono a re-inventare componenti, facendo ricerca e consegna allo stesso tempo e con le stesse persone!

Ciò porta inevitabilmente a prodotti una tantum, che sono costosi da sviluppare e fornire assistenza, sono soggetti a errori e falliscono in modi imprevedibili in condizioni incerte. E a causa di ciò, ovviamente, questi prodotti sono molto più obsoleti, scritti e sostituiti a costi altrettanto elevati con solo quelli leggermente migliori. Ciò di cui l'IT ha bisogno è l'equivalente della rivoluzione industriale, che ha trasformato gli artigiani della mezza età in fabbriche efficienti.

Detto questo, ci sono fattori che rendono l'IT veramente unica tuttavia. Al contrario di quelle altre industrie citate, l'IT è veramente onnipresente: è usato in ogni aspetto della nostra vita moderna. Quindi è un piccolo miracolo che l'IT abbia raggiunto questi progressi e sia in grado di fornire i risultati che fa.

Ho paura di non essere d'accordo con la tua affermazione.

Airbus e Boeing sono due esempi di aziende che costruiscono aerei. Quante aziende che costruiscono aerei ci sono? Pochissimi, se vuoi confrontarlo con quante aziende costruiscono software.

È altrettanto facile avvitare un progetto di aeroplano per avvitare un progetto software. Se solo la barriera di ingresso fosse così bassa nell'industria aeronautica come nell'industria del software, vedrai sicuramente molti progetti aerei falliti.

Guarda le auto; Ci sono produttori di alta qualità che costruiscono automobili molto resistenti e altamente avanzate (pensate a Land Rover, Mercedes) e ce ne sono alcune che costruiscono automobili che non dureranno un anno senza doverle riparare (si pensi a Kia o Cherry). Questo è un esempio perfetto di un settore con una barriera di ingresso leggermente inferiore, se cominciassi ad avere giocatori più deboli.

Il software non è diverso. Hai molti prodotti buggy, d'altra parte, Windows, Office, Linux, Chrome o Ricerca Google sono progetti di altissima qualità che sono stati consegnati in tempo e avevano un livello di qualità simile a quello di un aereo.

L'altro punto che manca a molte persone è la quantità di manutenzione necessaria per il mantenimento di un'automobile, un'autocisterna o un aeromobile che consideriamo come un dato di fatto. Ogni aereo deve sottoporsi a un controllo tecnico prima di ogni decollo. Devi controllare la tua auto ogni parecchi chilometri e fare cose regolari come cambiare l'olio, cambiare le gomme.

Anche il software ha bisogno. Se solo le persone spendessero tanto tempo in diagnostica, prevenzione o auditing sullo stato e la qualità del software come con prodotti meccanici / fisici, mi aspetterei un numero inferiore di affermazioni come queste. Leggi i log della tua applicazione ogni volta prima di avviarla? Bene ... se fosse un aereo dovresti; -)

I blocchi costitutivi digitali possono essere 1 o 0. Non c'è alcun inbetween.

Una progettazione meccanica ha un livello di tolleranza. Posso mettere un rivetto in meno di perfetto in un bridge e molto probabilmente non cadrà, tuttavia, anche in codice una sola istanza di mettere uno 0 dove dovrebbe essere un 1 può fallire l'intero programma.

A causa della natura logica e interativa dell'informatica, qualsiasi cambiamento, anche molto piccolo, può portare a un drastico fallimento.

Mi sono spesso chiesto la stessa cosa. Certamente si sente (occasionalmente) come se fossimo un gruppo di dilettanti che non hanno idea di cosa stiamo facendo. Non mi piacciono le spiegazioni che danno la colpa ai manager o ad altri fattori esterni: noi sviluppatori dovremmo essere responsabili di ciò che creiamo.

Penso che siamo in un business in cui gli errori sono economici . Il software di patching è economico, rispetto alla ricostruzione di un grattacielo o al richiamo di ogni cellulare venduto.

Questo ha creato una cultura in cui i bug fanno parte della vita di tutti i giorni . Sono accettati con un'alzata di spalle. Mentre alcuni bug sono probabilmente inevitabili, dovrebbero dominare il nostro lavoro quotidiano ? Capisco perfettamente i manager che non ritengono che il QA valga la pena, proprio perché si aspettano comunque dei bug. Non capisco i programmatori che non fanno ogni sforzo per produrre codice privo di errori, perché correggere bug è noioso da morire.

In sostanza, credo che sia un problema culturale e spero che cambierà.

Gli standard e le pratiche di ingegneria sono molto diversi nell'IT (come settore indipendente) rispetto a aerospaziale . Questo è forse più facile da capire considerando come reagiscono i professionisti IT quando incontrano documenti standard per IT in aerospaziale . Ad esempio, gli gli standard di C ++ di Joint Strike Fighter che hanno fatto il giro di Internet negli ultimi tempi.

Molti esprimono confusione o dimissioni malinconiche (vorrei poter fare in quel modo); e molti rispondono con il ridicolo, sostenendo che non esiste un modo pratico per fornire prodotti di consumo in questo modo. Questo potrebbe anche essere giusto, date le aspettative, non dei consumatori, ma della gestione. C'è molta sfiducia nei programmatori che codificano e codificano per poche settimane, non dimostrando nulla. Dio aiuta il programmatore che semplicemente progetta qualcosa per due settimane. Non così con gli aeroplani.

Nel software, le persone si aspettano davvero di avere qualcosa in questo momento. Certo, il ragionamento va, ci vorrà un po 'per averlo davvero solido; ma non possiamo avere una cosa complessa descritta in termini semplici in una settimana? Si impara, inoltre, che le cose complesse descritte in termini onesti e complessi raramente eccitano l'immaginazione; e così molti ingegneri finiscono per essere complici in un mondo immaginario di cose davvero semplici che vengono messe insieme in modi creativi (al contrario di un mondo di cose difficili fatte molto bene).

Alcune cose da me:

1- Standard e parti: sono produttori di piani, non sviluppatori. Non ne sono del tutto sicuro, ma la mia ipotesi è che molte parti siano esternalizzate. Non costruiscono i propri strumenti elettronici / elettronici, ricevono seggi da qualche azienda, i motori sono probabilmente sviluppati altrove, ecc.

I progetti software, d'altra parte, partono quasi sempre da zero con solo alcuni piccoli framework / helper sul posto.

2- Tempo per colpire il mercato: il tempo non è un problema critico per gli aerei. Scommetto che il progetto dell'Airbus è stato finalizzato anni prima che fosse terminato, e hanno scelto di trascurare eventuali importanti scoperte che potrebbero accadere in quel momento. (Lo stesso vale per le case automobilistiche, ad esempio, la tecnologia all'avanguardia che sviluppano in questo momento colpirà le strade in 5-10 anni.)

Per il software devi essere molto agile, se inizio subito un enorme progetto e impiegano tre anni per svilupparlo senza alcun cambiamento, le probabilità sono piuttosto alte che io faccia affidamento su una tecnologia che non è più disponibile o il mio prodotto è completamente obsolete. Questo a sua volta offre molti problemi.

3- Ciclo di rilascio e versioni. - Un aereo deve essere completamente finito quando viene "rilasciato". Non ci sono versioni beta stabili, build notturne o simili. Inoltre, una volta terminato, può essere modificato solo in un modo piccolo. Non è possibile aggiungere un ulteriore livello con 100 posti a un boeing esistente, non è possibile.

Il software d'altra parte ha cambiamenti incrementali che sono spesso solo "build che funzionano", ma non necessariamente prodotti finiti. Inoltre, in IT non è insolito dire "hey, aggiungiamo un altro compartimento bagagli al nostro aereo che contiene ulteriori 50 tonnellate".

Penso che la risposta sia abbastanza semplice:

1) La costruzione fisica e l'implementazione sono in circolazione da quando le persone hanno - abbiamo avuto migliaia di anni per sviluppare i nostri metodi e le tecniche per l'implementazione di progetti fisici. La "costruzione" del software, che richiede un set di abilità completamente nuovo e diverso, non ha più di 50 anni - non abbiamo ancora avuto abbastanza tempo per capire tutto.

2) La costruzione virtuale è più difficile - devi "vedere" le cose nella tua mente che non hanno alcuna realtà fisica. Ti richiede di analizzare e astrarre molte informazioni prima ancora di sapere come dovrebbe essere il tuo prodotto e i passi necessari per crearlo. Non così quando costruisci un ponte o un edificio.

3) Spesso è molto più difficile trovare la fonte di un errore o di un bug di software piuttosto che quando si fa l'ingegneria fisica. Se una trave si piega, si vede dove si sta piegando e si vedono i supporti che la trattengono e non funzionano, ecc. Trovare un difetto software può comportare l'esame di una grande quantità di codice e processi di interazione - difficile, dispendioso e non legato al leggi della fisica e della matematica nel modo in cui sono le strutture fisiche.

Proverò a rispondere usando una copia letterale di un articolo della musa incorporata di Jack Ganssle. Mentre questo dice firmware in tutto il mondo, sostituirlo mentalmente con il software.

Compared to What?

Firmware is the most expensive thing in the universe. In his wonderful book "Augustine's Laws," Norman Augustine, former Lockheed Martin CEO, tells a revealing story about a problem encountered by the defense community. A high performance fighter aircraft is a delicate balance of conflicting needs: fuel range vs. performance. Speed vs. weight. It seems that by the late 70s fighters were at about as heavy as they'd ever be. Contractors, always pursuing larger profits, looked in vain for something they could add that cost a lot, but which weighed nothing.

The answer: firmware. Infinite cost, zero mass. Avionics now accounts for more than half of a fighter's cost. That's a chunk of change when you consider the latest American fighter, the F-22, costs a cool third of a billion a pop. Augustine practically chortles with glee when he relates this story.

But why is software so expensive? Tom DeMarco once answered this question with these three words: compared to what? He went on to discuss relatively boring business cases, but that answer has resonated in my mind for years. Compared to what? With software we routinely create product behaviors of unprecedented complexity. Sure, the code's expensive. But never in the history of civilization has anyone built anything so intricate.

Consider the following bubble sort, lifted shamelessly from Wikipedia and not checked for accuracy:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

It's a mere 110 non-space characters, perhaps tossed off in an hour or two. Suppose we didn't have software and had to implement a sort using some other strategy. What would it cost?

A mechanical engineer might boast that his profession built sorters long before computers. Consider IBM's 1949-era model 82 card sorter (http://www.columbia.edu/acis/history/sorter.html) with a throughput of 650 cards per minute, rather less than our code snippet might manage even on a 4 MHz Z80. The model 82, of course, only sorted one column of a card at a time; to completely sort a deck could take dozens of passes.

How long did it take to design and build this beast? Years, no doubt. And its functionality pales compared to our code which is so much faster and which can handle gigantic datasets. But that was 1949. How long would it take to build a bubble sort from electronic components - without FPGAs and VHDL, or a CPU?

In an hour I managed a rough block diagram, one above the chip level (blocks have names like "adder," "16 bit latch" and the like). But the sequencing logic is clearly pretty messy so I've just tossed in a PLD, assuming at some point it wouldn't be too hard to write the appropriate equations. And, yes, perhaps that breaks the no-programmable-logic rule, but to design and debug all that logic using gates in any reasonable amount of time is as unlikely as buck-a-gallon gas.

Assuming 16 bit words and addresses, the circuit will need around a dozen 16 bit latches, adders, and the like. Plus memory. And I have no idea how the unsorted data arrives into the RAM or how the results get exported. Those are unspecified design requirements. The software-only solution naturally resolves these requirements just by the act of writing the function prototype.

Translating the rough block diagram to a schematic might take a day. Then there's the time to design and produce a PCB, order and load parts (and change the design to deal with the unexpected but inevitable end-of-life issues), and then of course make the circuit work. We could be talking weeks of effort and a lot of money for the board, parts and appropriate test equipment.

All this to replace 7 little lines of code. Few real embedded programs are less than 10,000; many exceed a million. How much hardware and how much engineering would be needed to replace a real, super-sized computer program?

Consider a real program like a spreadsheet. How much circuitry would it take to make one without a processor? It could be the size of a city.

Firmware is the most expensive thing in the universe, but only because of the unimaginable complexity of the problems it solves. But it's vastly cheaper than any alternative. So when your boss irritably asks why the software takes so long, you know what to say. Compared to what?

Così là! Software / firmware ha una complessità senza precedenti.

L'ingegneria e la gestione del software sono fondamentalmente diverse rispetto a molte altre aree di ingegneria. I risultati finali non sono fisici e il processo di produzione è il processo di progettazione e sviluppo. Creare un'altra copia di un pezzo di software ha essenzialmente un costo marginale zero; tutto il costo si trova nello sviluppo della prima copia.

A causa della relativa giovinezza dell'ingegneria e della gestione del software come disciplina, ci sono alcune informazioni errate e false che vengono ancora considerate come fatti ( vedi questo riferimento ) che ostacola lo sviluppo e l'ingegneria del software nel suo complesso.

Non tutti gli sviluppatori sono creati allo stesso modo. Alcuni sono buoni, altri sono, beh, no.

Prova a leggere il codice di altre persone tutto il tempo per avere un'idea di quello che sto dicendo. Troppe dichiarazioni logiche aggiuntive possono aggiungere rischi. Questi rischi possono portare a comportamenti malati o bug. Non ci sono abbastanza istruzioni logiche e ora hai riferimenti null. Il buon programmatore lo capisce e sa quando fare cosa e dove. Ma nessuno è perfetto. Le cose sono complesse Aggiungi il lavoro mal concepito degli altri ed è facile vedere come i progetti scappano.

Le cattedrali richiedevano fino a 100 anni per costruire.

Alcuni aeroplani Airbus hanno bisogno di 1 milione di linee di codice per funzionare.

Più tempo hai migliorato qualcosa, più miglioramenti ottieni, quindi dai all'industria del software un paio di secoli di errori di prova per migliorare, e vedremo quanto ci vuole per sviluppare un solido enorme progetto senza errori o difetti.

I progetti di grandi dimensioni si verificano spesso nelle grandi organizzazioni. Se non hai mai lavorato in una grande organizzazione, c'è una cosa che è garantita per uccidere prestazioni e produttività: la burocrazia.

Sorprendentemente, molte persone non sanno quale sia la burocrazia (è spesso confusa con la politica), o anche se / quando hanno un problema burocratico.

Recentemente abbiamo concluso un progetto per implementare l'autenticazione con smart card. Originariamente era stimato a tre mesi. Ci sono voluti 15 mesi. Non ci sono stati costi, budget, scopo o motivi tecnici per il ritardo. L'ambito era in realtà piuttosto ristretto, solo per gli account con privilegi elevati (account amministratore), circa 1.200 account totali.

Un altro fattore significativo sono i tuoi partner commerciali. Ciò includerebbe i venditori. Se i tuoi partner hanno un problema che introduce un ritardo nel tuo progetto, non ci sono molte opzioni che risolveranno il problema del ritardo. Non funzionano direttamente per te, e potresti non essere in grado di licenziare quella persona a un partner che potrebbe essere la causa. Il partner può essere licenziato, o può essere soggetto a sanzioni finanziarie o disincentivi, ma ciò non cambia il fatto che il progetto abbia subito un ritardo. Questo è esattamente ciò che è accaduto con Boeing quando hanno intrapreso una strategia di sourcing mastodontica con Boeing 787 Dreamliner .

Ho una versione più breve per te:

Qualunque cosa sia facile da fare, o semplificata, scriviamo un programma per farlo al posto nostro.

E poi combatti con il meta-processo, invece.

Non è vero di per sé, ma ogni giorno vengono creati migliaia di blog, invece di scrivere motori di blog. Ogni giorno lavorativo, vengono scritte migliaia di macro di Excel, invece di scrivere applicazioni di database appositamente progettate per queste.

Ci sono molti altri fattori, alcuni dei quali menzionati qui, ma volevo aggiungere questo punto alla discussione.

Mancanza di responsabilità ... Le persone vengono citate in giudizio quando un aereo si schianta. L'industria del software declina ogni responsabilità in qualsiasi difetto del software, creando quindi una mancanza di incentivi per creare un prodotto robusto e sicuro.

La maggior parte dei progetti di grandi dimensioni presenta un alto grado di separabilità dei sottoprogetti, in cui è possibile definire un numero limitato di vincoli di progettazione; l'intero progetto funzionerà quando questi sottoprogetti saranno completati. Se qualcosa va storto in un sottoprogetto, l'intero sforzo non viene messo in discussione; cerchi solo modi alternativi per completare il sottoprogetto (ad esempio, usa un motore diverso).

Questo è possibile ma difficile, sia in pratica che per questioni di natura umana, nei progetti software.

In parte, altre industrie hanno imparato a fondo che questo tipo di separabilità è una buona cosa. Ad esempio, se stai per utilizzare i motori di aerei Rolls Royce, non è necessario utilizzare bulloni speciali e punti di attacco di Rolls Royce che funzionano solo con le ali con un particolare design, e quindi se provi a passare a Pratt e Whitney, devi ridisegnare l'intera ala da terra (che, a sua volta, richiede una riprogettazione completa della fusoliera, che a sua volta richiede l'acquisto di diversi sedili, che a sua volta richiede l'acquisto di un diverso sistema di intrattenimento in volo, quale...). Ci possono essere alcuni collegamenti: non puoi semplicemente scambiare motori senza una cura, ma i grandi progetti generalmente funzionano meglio quando tali elementi sono ridotti al minimo.

Ho postulato che i grandi progetti software progettati come un cluster di piccoli progetti software con interfacce pulite tra loro non falliscano particolarmente spesso, a patto che il grande progetto sia effettivamente risolto dal cluster di piccoli progetti. (È possibile fare un errore in questo senso.)

Costruire sistemi software è molto diverso dalla costruzione di strutture fisiche. Cioè, l'implementazione è molto diversa. Mentre per esempio costruisci una grande nave cisterna, fai un sacco di compiti relativamente semplici (non facili!), Come la saldatura di parti insieme da un robot o a mano, stringendo tutti i dadi e bulloni, dipingendo, esegui la decorazione portando tutto in l'attrezzatura, i mobili e così via. Tutto questo è molto semplice cose da fare, davvero.

Tuttavia, quando si tratta di software, diventa molto più complesso . Ad esempio, in che modo esattamente implementa il login sicuro e le credenziali utente memorizzando parte del prodotto? Quali librerie e strumenti puoi usare? Con quali librerie e strumenti conosci? Come procederai esattamente nello scrivere la funzione hashing + salting e come ti assicuri che sia sicuro? Puoi farlo in così tanti modi che è impossibile impostare qualsiasi modello di progettazione per questo genere di cose. Sì, i suddetti modelli di design do esistono su una scala più piccola come "best practice", ma ogni singolo sistema software è molto diverso dagli altri, e il campo avanza e cambia a un ritmo così rapido che è essenzialmente impossibile da mantenere.

Quando costruisci una casa, non ti imbatti in questi problemi in cui ti rendi conto che i muri di supporto principali sembrano inadeguati e devono essere sostituiti, richiedendo di demolire i progressi finora e iniziare dalla base rifacendo le pareti di supporto. Affronta questi problemi nella fase design , perché è relativamente semplice prevedere quale tipo di muri di supporto sono necessari per l'edificio.

Tuttavia non è questo il caso del software. Non è possibile progettare l'intero prodotto come una singola entità e quindi implementarlo. Il processo di progettazione del software è solitamente iterativo e gli obiettivi e i requisiti cambiano man mano che il prodotto viene implementato e testato. Lo sviluppo del software nel suo complesso è un processo iterativo in cui le cose cambiano di solito quando meno previste, e molte volte tali cambiamenti impongono sfide che richiedono più lavoro, più complessità e, sfortunatamente, più denaro, tempo e duro lavoro per avere ragione.

Quindi, in sostanza, la ragione per cui è difficile fornire grandi progetti e stimare timeline del progetto e roadmap è che lo sviluppo del software e in particolare la progettazione del lavoro sono campi molto complessi . La complessità è il problema principale.

La definizione di "progetto grande" è distorta.

Un grande progetto, tecnicamente, può essere consegnato in tempo e in modo impeccabile, a condizione che sia qualcosa che è stato costruito molte, molte volte nel corso degli anni.

• Un clone di Pac-Man.
• Un calcolatore
• Un editor di testo

Sono sicuro che stai pensando ... "ma questi sono piccoli progetti! Un editor di testo è semplice ." Non sarei d'accordo con te. I computer sono oltraggiosamente complicati. Solo l'installazione e la configurazione degli utenti su un sistema operativo possono essere difficili a volte, e non hai nemmeno scrivi il sistema operativo, né costruito l'hardware.

I progetti di cui parli sono progetti enormi , simili all'esplorazione dello spazio. Come sai quanto tempo ci vuole per sviluppare i viaggi inter-galattici? Su quale modello basiamo? Hai i conosciuti conosciuti, le sconosciute conosciute, i conosciuti sconosciuti e, infine, le incognite sconosciute, che capitano molto nello sviluppo del software.

Penso che il problema sia di aspettativa. Solo perché la tecnologia è lì non significa che l'utilizzo avrà successo (o saggio da usare) per un po '. Se altre industrie si comportassero come le industrie del software, avremmo messo a disposizione degli aspirapolveri a buco nero entro la fine del decennio. O qualche "visionario" avrebbe le risorse per costruire una base lunare, e decidere che uno Starbucks avrebbe davvero "completato" l'esperienza per i visitatori. Non penso che il problema sia l'industria del software, ma le aspettative sono poste su .

Anche se non è certo l'unica cosa che potrebbe essere menzionata, penso che una cosa fondamentale sia da sottolineare. La maggior parte dei prodotti è pensata per adattarsi al comportamento esistente. Anche un prodotto che è una svolta radicale (ad esempio, l'auto) è generalmente costruito per adattarsi al comportamento esistente, e semplicemente lo rende un po 'più semplice / più facile / più economico / qualsiasi cosa per farlo. Sì, spesso c'è anche un effetto collaterale alcuni sul comportamento esistente (ad esempio, procurarsi carburante per la macchina anziché cibo per i cavalli), ma la maggior parte di questi tende ad essere un effetto collaterale piuttosto secondario.

Al contrario, quasi tutti i software che non modificano il comportamento degli utenti (per esempio, lasciano che facciano il loro lavoro molto più facilmente) è fondamentalmente garantito che si tratta di un fallimento completo dal primo giorno. Peggio ancora, i grandi progetti software don coinvolgere solo il comportamento degli utenti a livello individuale, ma il comportamento di gruppi numerosi, spesso l'intera organizzazione.

In breve, progettare il software stesso è spesso la parte più facile del lavoro. La parte difficile è ridisegnare il lavoro delle persone per loro. È difficile iniziare con; farlo in un modo che non solo funziona, ma anche essere accettato è ancora più difficile.

Airbus A380 non è stato un progetto di successo come lei ha menzionato. Mi è capitato di lavorare in una società CAD / CAM, e mi è stato detto che (avevamo anche il prioject dell'Airbus) è stato ritardato di alcuni anni, perché utilizzavano versioni diverse del software in società diverse. Cioè, diverse parti venivano progettate in diverse parti del mondo. E mentre si integrano, sono venuti a sapere che tutto il design non può essere integrato, quindi devono riprogettarlo in una versione. Quindi, a guardarlo, non penso che abbia avuto successo. Se fosse arrivato 2-3 anni prima, sarebbe stato rivoluzionario per Airbus.

Anche per quanto riguarda il software robusto, guardi qualsiasi aereo, automobile (ABS, EPS, climatizzazione, ecc.) o lo space shuttle hanno più del 50% di software che li sta eseguendo e credimi sono molto robusti. È solo che siamo più vicini al software e ci sono molti altri programmi software, quindi vediamo più errori in essi.

Visita: link e vedere quanto successo era Airbus A380.

Ingegnere informatico qui, con un background ingegneristico e una moglie che lavora nella costruzione. Abbiamo avuto lunghe discussioni (e discussioni) sulle differenze dei nostri lavori.

L'ingegneria del software riguarda la progettazione di nuove cose . Quasi tutto ciò che è di base è stato fatto in una libreria open source da qualche parte. In quasi tutti i lavori in cui viene assunto un ingegnere del software, deve progettare qualcosa che non esiste.

In qualcosa come la costruzione e la maggior parte delle forme di ingegneria, le cose che altrimenti sarebbero in una "libreria" nel software sono già completamente progettate. Vuoi costruire una torre? Basta copiare e incollare i piani da una struttura esistente, con alcune modifiche.

In effetti, uno dei motivi principali per cui ho deciso di non diventare un ingegnere è che passi la maggior parte del tempo a progettare un miglioramento del 10% rispetto a un'invenzione esistente, quando in quel momento potevi programmare qualcosa di più visibile, come un social network.

Non ci sono molti nuovi progetti in ingegneria; un ingegnere estremamente qualificato è qualcuno che può manipolare un progetto esistente in qualcosa di nuovo o migliorarlo. Ma quasi tutti i programmatori dovrebbero modificare i disegni, modificarli o creare qualcosa di nuovo.

Guarda in quale misura gli standard sono completamente cambiati, da assembly a C a C ++ a Java, JavaScript, C # , PHP e così via. Non c'è molto codice che può essere riciclato da 10 o 20 anni fa. Questo è molto diverso da dire ... l'industria automobilistica o aeronautica quando puoi continuare a migliorare sui progetti da decenni indietro.

La gestione del progetto è notoriamente difficile nel software . Le stime del tempo sono fatte meglio da persone che fanno il lavoro , ma quando sono impegnate a fare stime, non scrivono codice . Questo tenta di evitare qualsiasi gestione del progetto.

Spesso, un sacco di codice dipende da persone specifiche e se queste persone sono in ritardo o impossibilitate a eseguire, il codice non procede. Al contrario, se si voleva costruire un'auto, è possibile assumere semplicemente persone diverse per assemblare pneumatici, telaio, batteria, motore e così via. I framework object oriented e quelli esistenti lo rendono possibile, ma potrebbe non essere pratico quando si sta progettando tutto da zero.

Potrebbero essere consentiti errori nel software . I test possono essere costosi. Nel software, è molto allettante saltare tutti i test, quando si può semplicemente correggere un crash. Nella maggior parte delle forme di ingegneria, un "crash" può essere fatale.

Esistono metodi di programmazione che utilizzano test approfonditi, come programmazione estrema (che è stato effettivamente utilizzato nei megaprogetti software). Ma con scadenze ravvicinate (che possono essere rese più stringenti di proposito), si sta tentando di saltare tutta quella programmazione e lanciare con bug. Lo stile Joel Spolsky di "correggere sempre tutti i bug" farà risparmiare più tempo a lungo termine, ma l'indisciplinato salterà questo e fallire.

I piccoli progetti sono migliori . Una volta mia moglie mi ha chiesto di trovare un lavoro in una grande azienda. È finito in una discussione che le grandi aziende sono cattive compagnie ... per lei, una grande azienda aveva un sacco di risorse, esperienza, gestione funzionale del progetto e le giuste procedure. Per me, una grande azienda è un dinosauro, dove la maggior parte del tuo tempo è dedicato alla riparazione del codice, al test e alla documentazione.

Ho visto lavorare progetti IT da milioni di dollari su meno di 10 persone. Un numero maggiore di persone avrebbe rallentato il progetto e aggiunto inutili oneri burocratici. WhatsApp è un esempio di un progetto "piccolo" che vale miliardi di dollari. Non è che i grandi progetti non siano possibili, ma semplicemente non hai bisogno di migliaia di persone per produrre miliardi di dollari in software.

Una delle ragioni che non è stata affrontata nelle altre domande è che il campo del software si rinnova a una velocità che si verifica solo raramente nel mondo basato sui materiali.

Una ragione di ciò è che l'evoluzione del software è un ciclo di feedback positivo perché il software (linguaggi di programmazione, strumenti di costruzione, IDE) viene utilizzato per creare software. È l'esempio più ovvio per la legge di accelerazione dei resi, di Ray Kurzweil con conseguente progresso a velocità esponenziale crescente. Una volta che hai padroneggiato un framework, il linguaggio di programmazione, il protocollo di comunicazione è tempo di passare a alla successiva.

Se gli aeroplani fossero costruiti come un software, dovremmo cambiare il materiale con ogni altro modello, raddoppiare la loro capacità e velocità ogni 18 mesi, sostituire la tecnologia del motore per ogni nuovo modello con qualcosa appena inventato, aggiungendo la possibilità di nuotare e cerca la vita extraterrestre.

Oh, e idealmente ascolta i comandi vocali e raddoppia come un cinema completamente immersivo, un'arena di paintball e un night club con una stanza buia una volta terminato il tuo viaggio di lavoro. La stessa cosa! (La compagnia che costruì aeroplani che ti facevano affidare in modo affidabile da A a B andò a pancia in piedi un anno dopo che uscì quella con la funzione cinema, paintball e nightclub.)

Per me il problema principale dell'ingegneria del software sono casi d'uso, piattaforme utente e cross.

Use cases

Quanti casi d'uso ha un aeroplano? La maggior parte è solo per volare da un posto all'altro. Forse ci sono più come radar, controllo del traffico, ecc., Ma il caso d'uso è chiaro e non molto. Nell'ingegneria del software, ci troviamo di fronte a requisiti poco chiari e utenti che non sanno cosa vogliono. Utente diverso ha bisogno di configurazione / flusso diversi, può un aereo essere personalizzato come desidera l'utente (voglio avere tv e frigorifero!)?

utente

Chi gestisce un aeroplano? Un pilota, un copilota, alcuni steward (se contati) e operatori di torri. Sono tutti professionisti e hanno le loro descrizioni di lavoro chiare. I software sono utilizzati da noob e manichini, per non parlare di hacker e cracker malvagi, mentre devono ancora essere integrabili con altri moduli (come OpenID o Google AdSense ). Se un aereo può essere azionato da un manichino mentre sopravvivi ancora a missili o briganti ninja, allora puoi dire che l'aereo ha la stessa qualità del software.

Piattaforme incrociate

Un aeroplano vola solo nel cielo della terra. Non sono sicuro di come gestiscono il clima nebbioso o ventoso o caldo, freddo e umido, ma un aereo non è progettato per volare a un livello di gravità diverso (sarei sorpreso se potesse volare a Mars ). A volte, un'applicazione deve sopravvivere a piattaforme diverse, come Internet Explorer, Google Chrome , Firefox e Safari per browser (spiacente Opera ), o Windows XP / 7/8 o Linux per il livello OS. Per non parlare di dispositivi mobili e diverse risoluzioni e orientamenti.

Se pensi che altri settori completino progetti senza incidenti, dovresti leggere la storia sull'edificio Citigroup Center costruito nel 1977. Anche dopo quasi 7 anni di progettazione e costruzione, l'edificio è stato completato con un grave difetto di progettazione che avrebbe causato un collasso da un evento di tempesta previsto ogni 16 anni.

In other words, for every year Citicorp Center was standing, there was about a 1-in-16 chance that it would collapse.

I designer originali non erano a conoscenza dei problemi, ma per fortuna è stato catturato da uno studente che studiava l'edificio.

everything seemed just fine—until, as LeMessurier tells it, he got a phone call. According to LeMessurier, in 1978 an undergraduate architecture student contacted him with a bold claim about LeMessurier’s building: that Citicorp Center could blow over in the wind.

Le riparazioni sono state fatte letteralmente nella copertina della notte che coinvolgono il minor numero di persone per mantenere la segretezza del difetto di progettazione.

È stato preparato un piano di evacuazione di emergenza per il raggio di 10 blocchi che circonda l'edificio.

They welded throughout the night and quit at daybreak, just as the building occupants returned to work.

The story remained a secret until writer Joe Morgenstern overheard it being told at a party, and interviewed LeMessurier. Morgenstern broke the story in The New Yorker in 1995.

Che solleva la domanda; quanti altri difetti di progettazione fatale nei progetti sono stati segretamente riparati o ignorati senza riconoscimento pubblico.

• Il difetto di progettazione che ha quasi spazzato via un grattacielo di New York (slate.com)
• Centro Citigroup (wikipedia.com)