Perché il settore IT non può realizzare rapidamente progetti di grandi dimensioni e senza difetti come in altri settori?

Dopo aver visto la serie MegaStructures di National Geographic , sono rimasto sorpreso dalla rapidità con cui sono stati completati i grandi progetti. Una volta svolto il lavoro preliminare (design, specifiche, ecc.) Su carta, la realizzazione stessa di grandi progetti richiede solo pochi anni o talvolta alcuni mesi .

Ad esempio, Airbus A380 "lanciato ufficialmente il 19 dicembre 2000" e "all'inizio di marzo 2005" , l'aereo era già stato testato. Lo stesso vale per enormi petroliere, grattacieli, ecc.

Confrontando questo con i ritardi nell'industria del software, non posso fare a meno di chiedermi perché la maggior parte dei progetti IT sia così lenta, o più precisamente, perché non possano essere così veloci e impeccabili, alla stessa scala, dati abbastanza persone?

Progetti come Airbus A380 presentano entrambi:

• Principali rischi imprevisti: sebbene questo non sia il primo aereo costruito, spinge ancora i limiti della tecnologia e le cose che hanno funzionato bene per gli aerei di linea più piccoli potrebbero non funzionare per quello più grande a causa di vincoli fisici; allo stesso modo, vengono utilizzate nuove tecnologie che non erano ancora state utilizzate, perché ad esempio non erano disponibili nel 1969 quando Boeing 747 fu realizzato.

• Rischi connessi alle risorse umane e alla gestione in generale: persone che abbandonano nel mezzo del progetto, incapacità di raggiungere una persona perché è in vacanza, errori umani ordinari, ecc.

Con questi rischi, le persone realizzano ancora progetti come quei grandi aerei di linea in un periodo di tempo molto breve e, nonostante i ritardi di consegna, quei progetti hanno ancora un enorme successo e di alta qualità.

Quando si tratta di sviluppo software, i progetti non sono così grandi e complicati come un aereo di linea (sia tecnicamente che in termini di gestione) e presentano rischi leggermente meno imprevisti dal mondo reale.

Tuttavia, la maggior parte dei progetti IT sono lenti e in ritardo e l'aggiunta di più sviluppatori al progetto non è una soluzione (passare da un team di dieci sviluppatori a duemila a volte permetterà di consegnare il progetto più velocemente, a volte no, e a volte danneggerà solo il progettare e aumentare il rischio di non finirlo affatto).

Quelli che vengono ancora consegnati possono spesso contenere molti bug, che richiedono service pack consecutivi e aggiornamenti regolari (immagina "l'installazione di aggiornamenti" su ogni Airbus A380 due volte alla settimana per correggere i bug nel prodotto originale e prevenire il crash dell'aeromobile).

Come si possono spiegare tali differenze? È dovuto esclusivamente al fatto che l'industria dello sviluppo software è troppo giovane per essere in grado di gestire migliaia di persone in un singolo progetto al fine di fornire prodotti su larga scala, quasi senza errori molto velocemente?

La Marcia della morte di Ed Yourdon tocca alcune di queste domande sul meta-tipo.

In generale, all'industria del software mancano molte delle cose seguenti, che ostacolano i grandi progetti.

• Standardizzazione e scomposizione degli elementi di lavoro.

  • Questo è sicuramente migliorato, ma i costrutti di design non sono ancora lì per rompere un grande sistema. In un certo senso, il software non può nemmeno essere d'accordo su ciò che è necessario per un determinato progetto, tanto meno essere in grado di scomporre le cose in componenti.
  • Aerospace, edilizia, auto, ecc. Tutti hanno architetture guidate da componenti con interfacce ragionevolmente strette per consentire uno sviluppo completamente parallelo. Il software consente ancora un eccessivo spurgo nelle aree corrispondenti.

• Un gran numero di progetti simili e di successo. L'A380 non è stato il primo grande aereo che Airbus ha costruito. Ci sono molte grandi applicazioni software là fuori, ma molte di esse hanno sofferto in modo drammatico in un aspetto o nell'altro e non si avvicinano ad essere chiamate "di successo".

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

• "Mai" costruire la stessa cosa due volte. In molti modi, un aeroplano è come qualsiasi altro aeroplano. Ha ali, motori, sedili, ecc. I grandi progetti software raramente si ripetono. Ogni kernel del sistema operativo è significativamente diverso. Guarda la disparità nei file system. E del resto, quanti SO davvero unici ci sono? I più grandi diventano cloni di un elemento base ad un certo punto. AIX , Solaris , HP-UX , ... herald 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 risalgono tutte allo stesso core avviato da Linus. Lo sostengo, perché le varianti tendono a propagarsi più velocemente dei sistemi operativi proprietari davvero unici.

• Stima del progetto davvero pessima. Poiché il fattore di ripetibilità è così basso, è difficile prevedere quanto sarà grande e quanto tempo impiegherà a costruire. Dato che i project manager e la direzione non possono mettere le mani sul codice e vedere effettivamente cosa si sta facendo, vengono generate aspettative non realistiche riguardo alle tempistiche.

• Il QA / QC non è enfatizzato nel modo più intenso che potrebbe o dovrebbe essere per progetti più grandi. Ciò risale al fatto di avere interfacce più libere tra i componenti e di non avere specifiche rigide su come dovrebbero funzionare i componenti. Questa scioltezza consente conseguenze non intenzionali e l'insorgenza di bug.

• Qualifiche coerenti e misurabili. Generalmente, le persone parlano del numero di anni in cui hanno lavorato nel linguaggio X o nella programmazione. Time in viene utilizzato come sostituto del calibro o della qualità delle abilità. Come è stato menzionato molte volte, è difficile intervistare e trovare bravi talenti della programmazione. Parte del problema è che la definizione di "buono" rimane molto soggettiva.

Non intendo essere tutto negativo, e penso che l'industria del software abbia fatto passi da gigante da dove siamo stati. Forum come questo e altri hanno davvero contribuito a promuovere la conversazione e la discussione dei principi di progettazione. Ci sono organizzazioni che lavorano per standardizzare le conoscenze "di base" per gli ingegneri del software. Vi sono certamente margini di miglioramento, ma penso che l'industria abbia fatto molta strada in un periodo di tempo ragionevolmente breve.

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

Molti progetti in altri settori impiegano molto più tempo del previsto, costano molto di più o semplicemente non vedono mai il completamento. Suona familiare?

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

Nel software non esiste una linea di produzione nota. Costruire il componente finale è (relativamente) economico, e la replica di quel prodotto finale è sia perfetta che efficacemente gratuita: copi i manufatti di costruzione.

Per evidenziare alcune cifre:

1. Modifica dei requisiti dopo l'avvio dell'attuazione ; per esempio, quando il primo Airbus A380 iniziò a essere creato in fabbrica, non posso credere che se qualcuno volesse altri 200 posti a sedere, quelli sarebbero stati 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 di tipo umano progettati e sviluppati;
3. Non sono state spese risorse sufficienti in fase di architettura e progettazione ;
4. Immaturità sul campo : l'ingegneria del software è una disciplina relativamente giovane rispetto ad altre sorelle dell'ingegneria; ciò ha due implicazioni: a) Non così tante euristiche e buone pratiche; b) Non così tanti specialisti di grande esperienza;
5. Mancanza di prove matematiche - nella maggior parte dei casi i metodi matematici formali non vengono utilizzati per dimostrare che un software funziona come richiesto; invece viene utilizzato il test. Questo è vero in altri campi dell'ingegneria che si basano maggiormente sulla matematica; la ragione di ciò è come 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 elevate (soprattutto nei tempi di consegna) da parte dei programmatori e non capisco esattamente quanto sia difficile programmare software di grandi dimensioni.

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

Nel caso dell'A380 gran parte del ritardo è stato causato dalle unità francesi e tedesche di Airbus utilizzando versioni diverse e leggermente incompatibili del software di progettazione CATIA . Ciò si è manifestato in modo incompatibile come cablaggi che non si adattavano perfettamente al velivolo.

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

Il Boeing 787 soffriva anche di ritardi legati al software, ma la maggior parte dei suoi problemi riguardava nuovi problemi aerei più tradizionali come il controllo del peso e la consegna di componenti scadenti da parte dei fornitori.

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

Grandi progetti complessi 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 far luce su vari elementi del thread. Gli edifici si verificano davvero molto velocemente. Un vincolo importante è la localizzazione (regolamenti). Ma in generale ci vogliono dai 3 ai 10 anni per un edificio alto dall'inizio alla fine.

Penso che confrontare un nuovo edificio con un nuovo progetto software non sia molto preciso. Un nuovo edificio è più vicino a una nuova versione di un kernel o sistema operativo. Sotto questo aspetto lo sviluppo del software è molto più veloce. Non costruiamo mai da zero in quanto questo sarà un compito ad alto rischio per il quale il cliente non si iscriverebbe mai. La maggior parte della progettazione e dello sviluppo negli edifici deriva da progetti comprovati e completati.

Per esperienza personale, solo un progetto su dieci viene mai realizzato. Il processo è guidato dallo sviluppo piuttosto che dal design, quindi nel 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 essere concepito schematicamente, 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 eolici, ingegneri dei servizi, consulenti di quantità e costi, geometri, ingegneri dell'accessibilità e l'elenco continua ...

L'argomento virtuale contro fisico non è molto preciso. Lavoriamo anche principalmente con strumenti virtuali e inoltre siamo lontani dal tempo e dalla scala del nostro prodotto finale. Nella maggior parte dei casi non possiamo nemmeno testare aspetti di edifici in scala mockup e usiamo la simulazione per provare a prevedere cosa potrebbe accadere.

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

Per quanto riguarda l'argomento del design rispetto allo sviluppo, penso che entrambi i processi siano costruiti in base al design. Sembra accademicamente bello tenerli separati, ma non è possibile progettare se non si sa come funzionano le cose. Basta aumentare il rischio di fallimento.

Nel complesso la mia stima (potenzialmente errata) secondo la domanda di OP è che la programmazione è più un'arte che ingegneria. Perché le persone dovrebbero provare piacere e persino farlo gratuitamente, trovare espressione ed eleganza in esso? L'informatica è anche (come sulla carta) più una scienza che ingegneria. Perché dovresti provare a provare algoritmi invece di mettere semplicemente insieme le parti esistenti e lavorare per far funzionare le cose? Non sono sicuro se questo abbia un senso; Non sono un tipo di software.

Un aspetto che mi colpisce con la progettazione e lo sviluppo del software riguarda il mezzo stesso. I computer rendono il lavoro incentrato sull'uomo molto innaturale. Tutto è molto esplicito e ci sono poche tolleranze. È difficile aggirare mentalmente ciò, e alcuni riescono a evitarlo scaricando la complessità all'interno. Se nient'altro questo potrebbe avere qualcosa a che fare con esso?

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

Sulla base di questo articolo , si sta lentamente comprendendo 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 personale esperto ed è impossibile pianificare, poiché anche piccole modifiche ai requisiti possono comportare enormi cambiamenti nell'architettura complessiva del progetto. Questa comprensione è la base per metodologie agili che si concentrano sul miglioramento della qualità del codice come documento di progettazione finale e sull'esecuzione di test e debug come parte del processo di progettazione, proprio come testano i modelli di aeroplani nelle gallerie del vento.

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

Il motivo per cui i progetti software sono terminati con enormi ritardi e costi gonfiati è perché i manager pensano ancora di poter stimare, prevedere e pianificare tale processo di progettazione. Questo fallisce più spesso di quanto sia effettivamente valido. Pensano ancora che legando le persone a un rigido processo di costruzione possano in qualche modo aumentare la qualità anche se il risultato finale è per lo più opposto all'aumento dei costi e delle scadenze mancate.

Immagina, nel bel mezzo del progetto dell'Airbus A380, qualcuno ha convocato in una riunione e ha detto: "Heh, potrebbe costruirlo come triplano?" Altri si unirono dicendo: "Sì, sì. Un triplano. Altre ali sono meglio." I prossimi anni vengono trascorsi trasformando il design dell'A380 in una triplano. In un altro incontro, qualcuno dice "Un triplano? È vecchio. Vogliamo un biplano. Basta rimuovere una delle ali."

O immagina, nel mezzo di un progetto di costruzione di un ponte, qualcuno dice: "Heh, abbiamo appena fatto un accordo con una compagnia di navigazione. Hanno bisogno che il ponte sia più alto di 40 piedi, perché le loro navi sono molto più alte. Risolvilo. Grazie. ".

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

Come persona con un background di ingegneria meccanica che lavora nell'IT, mi sono spesso interrogata sulle ragioni del basso tasso di successo nell'IT.

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

Altre industrie, come l'edilizia o la costruzione navale hanno anche molti più "percorsi battuti": conoscenza ed esperienza di un particolare prototipo di soluzione, che - in forma personalizzata - viene riutilizzato più volte. Vi siete mai chiesti perché gli edifici, le navi o gli aeroplani di dimensioni e scopi diversi abbiano un aspetto così simile? (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 si potesse fare diversamente. Nella standardizzazione IT raramente accade: i progetti (di grandi dimensioni) tendono a reinventare i componenti, facendo ricerca e consegna allo stesso tempo e con le stesse persone!

Ciò porta inevitabilmente a prodotti unici, che sono costosi da sviluppare e riparare, sono soggetti a errori e falliscono in modo imprevedibile in condizioni incerte. E per questo motivo, naturalmente, questi prodotti sono molto più rapidamente obsoleti, scritti e sostituiti a costi altrettanto elevati con solo leggermente migliori. Ciò di cui l'IT ha bisogno è l'equivalente della rivoluzione industriale, che ha trasformato gli artigiani di mezza età in efficienti fabbriche.

Detto questo, ci sono fattori che rendono l'IT davvero unico. A differenza di quegli altri settori citati, l'IT è veramente onnipresente: viene utilizzato in ogni aspetto della nostra vita moderna. Quindi è un piccolo miracolo che l'IT abbia raggiunto questi progressi ed è in grado di fornire i risultati che fa.

Temo di non essere d'accordo con la tua affermazione.

Airbus e Boeing sono due esempi di compagnie che costruiscono aerei. Quante aziende che costruiscono aerei ci sono? Pochissimi, se lo paragonassi a quante aziende costruiscono software.

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

Guarda le macchine; Ci sono produttori di alta qualità che costruiscono automobili molto resistenti e altamente avanzate (pensa Land Rover, Mercedes) e ci sono quelli che costruiscono automobili che non dureranno un anno senza doverle riparare (pensa Kia o Cherry). Questo è un esempio perfetto di un settore con una barriera d'ingresso leggermente inferiore, se inizi ad avere giocatori più deboli.

Il software non è diverso. Hai un sacco di prodotti difettosi, 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 la manutenzione di un'auto, una nave cisterna o un aereo che consideriamo un fatto reale. Ogni aereo deve essere sottoposto a un controllo tecnico prima di ogni decollo. Devi controllare la tua auto ogni qualche chilometro e fare cose regolari come cambiare l'olio, cambiare le gomme.

Anche il software ha bisogno di questo. Se solo le persone dedicassero tanto tempo alla diagnostica, alla prevenzione o al controllo dello stato e della qualità del software rispetto ai prodotti meccanici / fisici, mi aspetterei molte meno affermazioni come queste. Leggete i registri dell'applicazione ogni volta prima di avviarlo? Bene .. se fosse un aereo avresti dovuto ;-)

I blocchi digitali possono essere 1 o 0. Non ci sono intermezzi.

Una progettazione meccanica ha un livello di tolleranza. Posso mettere un rivetto meno che perfetto in un bridge e molto probabilmente non cadrà, tuttavia, nel codice anche solo una volta l'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, anche piccolissima modifica, può portare a un drastico fallimento.

Mi sono spesso chiesto la stessa cosa. Sicuramente sembra (occasionalmente) che siamo 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 gli insetti fanno parte della vita quotidiana . 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 i bug è noioso da morire.

In sostanza credo che sia un problema culturale e spero che cambi.

Gli standard e le pratiche di ingegneria sono molto diversi nell'IT (come settore indipendente) rispetto all'aerospaziale . Ciò è forse più facilmente comprensibile considerando come reagiscono i professionisti IT quando incontrano documenti standard per l' IT nel settore aerospaziale . Ad esempio, gli Standard C ++ Joint Strike Fighter che negli ultimi tempi hanno fatto il giro di Internet.

Molti esprimono divertimenti o dimissioni malinconiche (desideriamo poter fare così); e molti rispondono con ridicolo, sostenendo che non esiste un modo pratico per fornire prodotti di consumo in questo modo. Questo può anche essere giusto, date le aspettative, non dei consumatori, ma della gestione. C'è molta sfiducia nei confronti dei programmatori che si limitano a codificare e codificare per alcune settimane, non dimostrando nulla. Dio aiuta il programmatore che si limita a progettare 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 'di tempo per renderlo davvero solido; ma non possiamo avere qualcosa di complesso descritto in termini semplici in una settimana? Si impara anche che le cose complesse descritte in termini onesti e complessi raramente stimolano l'immaginazione; e così molti ingegneri finiscono per essere complici in un mondo immaginario di cose davvero semplici messe insieme in modi creativi (al contrario di un mondo di cose difficili che si fa davvero bene).

Alcune cose da me:

1- Standard e parti: sono produttori di aerei , non sviluppatori. Non ne sono del tutto sicuro, ma la mia ipotesi è che molte parti siano esternalizzate. Non costruiscono i propri strumenti / elettronici, ottengono posti da alcune società, i motori sono probabilmente sviluppati altrove, ecc.

I progetti software, d'altra parte, iniziano quasi sempre da zero con solo alcuni piccoli framework / helper in atto.

2- Tempo per colpire il mercato: il tempo non è un problema critico per gli aerei. Scommetto che il design dell'Airbus fu finalizzato anni prima che fosse terminato, e decisero di trascurare qualsiasi grande passo avanti che potesse accadere in quel momento. (Lo stesso vale per le case automobilistiche, ad esempio, la tecnologia all'avanguardia che sviluppano al momento arriverà in strada tra 5-10 anni.)

Per il software devi essere molto agile, se inizio un grande progetto ora e impiego tre anni per svilupparlo senza alcun cambiamento, è molto probabile che io faccia affidamento su una tecnologia che non è più disponibile o che il mio prodotto è completamente obsoleto. 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 piccolo. Non è possibile aggiungere un livello aggiuntivo con 100 posti a un boeing esistente, semplicemente non è possibile.

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

Penso che la risposta sia abbastanza semplice:

1) La costruzione e l'implementazione fisica sono in circolazione da tanto tempo quanto le persone: abbiamo avuto migliaia di anni per sviluppare i nostri metodi e tecniche per implementare 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 capirlo.

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

3) Spesso è molto più difficile trovare l'origine di un errore o bug del software rispetto a quando si fa ingegneria fisica. Se una trave si piega, vedi dove si piega e vedi i supporti che lo trattengono e falliscono, ecc. La ricerca di un difetto del software può comportare l'esame di una grande quantità di codice e processi di interazione: difficile, che richiede tempo e non legato al leggi della fisica e della matematica come sono le strutture fisiche.

Proverò a rispondere usando una copia integrale di un articolo della musa incorporata di Jack Ganssle. Mentre questo dice firmware ovunque, basta sostituirlo mentalmente con un software.

Rispetto a cosa?

Il firmware è la cosa più costosa nell'universo. Nel suo meraviglioso libro "Augustine's Laws", Norman Augustine, ex CEO di Lockheed Martin, racconta una storia rivelatrice di un problema riscontrato dalla comunità della difesa. Un aereo da caccia ad alte prestazioni è un delicato equilibrio di esigenze contrastanti: autonomia di carburante vs. prestazioni. Velocità vs. peso. Sembra che alla fine degli anni '70 i combattenti fossero più o meno pesanti che mai. Gli appaltatori, perseguendo sempre profitti maggiori, cercarono invano qualcosa che potessero aggiungere che costasse molto, ma che non pesava nulla.

La risposta: firmware. Costo infinito, massa zero. L'avionica ora rappresenta oltre la metà del costo di un combattente. Questo è un pezzo di cambiamento se si considera l'ultimo combattente americano, l'F-22, costa un bel terzo di miliardo di dollari al pop. Agostino ridacchia praticamente di gioia quando racconta questa storia.

Ma perché il software è così costoso? Tom DeMarco una volta ha risposto a questa domanda con queste tre parole: rispetto a cosa? Ha continuato a discutere casi aziendali relativamente noiosi, ma quella risposta mi è risuonata nella mente per anni. Rispetto a cosa? Con il software creiamo abitualmente comportamenti di prodotto di complessità senza precedenti. Certo, il codice è costoso. Ma mai nella storia della civiltà qualcuno ha mai costruito qualcosa di così intricato.

Considera il seguente ordinamento a bolle, rimosso spudoratamente da Wikipedia e non verificato per la precisione:

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]);

}

Sono solo 110 personaggi non spaziali, forse gettati via in un'ora o due. Supponiamo di non avere software e di dover implementare un ordinamento usando qualche altra strategia. Quanto costerebbe?

Un ingegnere meccanico potrebbe vantarsi che la sua professione ha costruito sorter molto prima dei computer. Considera lo smistatore di carte IBM modello 82 del 1949 ( http://www.columbia.edu/acis/history/sorter.html ) con un throughput di 650 carte al minuto, un numero inferiore rispetto a quello che il nostro frammento di codice potrebbe gestire anche a 4 MHz Z80. Il modello 82, ovviamente, ordinava solo una colonna di una carta alla volta; per ordinare completamente un mazzo potrebbero essere necessarie decine di passaggi.

Quanto tempo ci è voluto per progettare e costruire questa bestia? Anni, senza dubbio. E la sua funzionalità impallidisce rispetto al nostro codice che è molto più veloce e in grado di gestire set di dati giganteschi. Ma era il 1949. Quanto tempo ci vorrebbe per costruire una sorta di bolla a partire da componenti elettronici - senza FPGA e VHDL, o una CPU?

In un'ora ho gestito un diagramma a blocchi approssimativo, uno sopra il livello del chip (i blocchi hanno nomi come "adder", "16 bit latch" e simili). Ma la logica del sequenziamento è chiaramente piuttosto disordinata, quindi ho appena lanciato un PLD, supponendo che ad un certo punto non sarebbe troppo difficile scrivere le equazioni appropriate. E, sì, forse ciò infrange la regola della logica non programmabile, ma progettare ed eseguire il debug di tutta quella logica usando le porte in un ragionevole lasso di tempo è improbabile come un dollaro al litro.

Supponendo parole e indirizzi a 16 bit, il circuito avrà bisogno di circa una dozzina di chiavistelli, additivi e simili a 16 bit. Più memoria. E non ho idea di come i dati non ordinati arrivino nella RAM o come vengano esportati i risultati. Questi sono requisiti di progettazione non specificati. La soluzione esclusivamente software risolve naturalmente questi requisiti semplicemente scrivendo il prototipo della funzione.

La traduzione del diagramma a blocchi approssimativo in uno schema potrebbe richiedere un giorno. Poi c'è il tempo di progettare e produrre un PCB, ordinare e caricare parti (e cambiare il design per affrontare i problemi inaspettati ma inevitabili di fine vita), e quindi ovviamente far funzionare il circuito. Potremmo parlare settimane di sforzi e un sacco di soldi per la scheda, le parti e le attrezzature di prova appropriate.

Tutto questo per sostituire 7 piccole righe di codice. Pochi programmi embedded reali sono meno di 10.000; molti superano il milione. Quanto hardware e quanta ingegneria sarebbe necessaria per sostituire un vero e proprio programma di computer di grandi dimensioni?

Prendi in considerazione un programma reale come un foglio di calcolo. Quanti circuiti ci vorrebbe per realizzarne uno senza un processore? Potrebbe essere la dimensione di una città.

Il firmware è la cosa più costosa nell'universo, ma solo a causa della complessità inimmaginabile dei problemi che risolve. Ma è molto più economico di qualsiasi alternativa. Quindi, quando il tuo capo chiede in modo irritante perché il software impiega così tanto tempo, sai cosa dire. Rispetto a cosa?

Quindi eccolo! Il software / firmware presenta una complessità senza pari.

L'ingegneria e la gestione del software sono sostanzialmente 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. La creazione di un'altra copia di un software ha un costo marginale sostanzialmente nullo; tutto il costo si trova nello sviluppo della prima copia.

A causa della giovinezza relativa dell'ingegneria e della gestione del software come disciplina, ci sono alcune informazioni sbagliate e falsità che sono ancora prese in considerazione ( vedi questo riferimento ) che ostacolano lo sviluppo e l'ingegneria del software nel suo insieme.

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

Prova a leggere il codice di altre persone continuamente per avere un'idea di ciò che sto dicendo. Troppe dichiarazioni logiche aggiuntive possono aggiungere rischi. Questi rischi possono portare a comportamenti scorretti o bug. Dichiarazioni logiche insufficienti 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.

La costruzione delle cattedrali impiegava fino a 100 anni.

Alcuni aerei Airbus necessitano di 1 milione di righe di codice per funzionare.

Più tempo stai migliorando, 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 progetto senza errori o difetti.

Grandi progetti si verificano spesso in grandi organizzazioni. Se non hai mai lavorato in un'organizzazione di grandi dimensioni, c'è una cosa che è certa di uccidere prestazioni e produttività: la burocrazia.

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

Di recente abbiamo concluso un progetto per l'implementazione dell'autenticazione con smart card. È stato originariamente stimato in tre mesi. Ci sono voluti 15 mesi. Non ci sono stati costi, budget, ambito o motivi tecnici per il ritardo. Il campo di applicazione era in realtà piuttosto limitato - solo per account con privilegi elevati (account amministratore), circa 1.200 account totali.

Un altro fattore significativo sono i tuoi partner commerciali. Ciò include i fornitori. Se i tuoi partner hanno un problema che introduce un ritardo nel tuo progetto, non ci sono molte opzioni che risolveranno effettivamente il problema del ritardo. Non funzionano direttamente per te e potresti non essere in grado di licenziare quella persona contro un partner che potrebbe essere la causa. Il partner può essere licenziato o essere soggetto a sanzioni pecuniarie 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 gigantesca strategia di approvvigionamento con il 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.

Di per sé non è molto vero, ma ogni giorno vengono creati migliaia di blog, anziché scrivere motori di blog. Ogni giorno lavorativo vengono scritte migliaia di macro di Excel, anziché 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 merito a qualsiasi difetto del software, creando quindi una mancanza di incentivi per creare un prodotto robusto e sicuro.

I progetti più grandi hanno 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 ciascuno. 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 praticamente che come questione di natura umana, in 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 degli aeromobili Rolls Royce, non è necessario utilizzare bulloni e punti di attacco Rolls Royce speciali che funzionano solo con ali con un design particolare, quindi se provi a passare a Pratt e Whitney, devi ridisegnare l'intera ala da zero (che, a sua volta, richiede una riprogettazione completa della fusoliera, che a sua volta richiede di acquistare diversi posti, che a sua volta richiede di acquistare un diverso sistema di intrattenimento in volo, quale...). Potrebbero esserci alcuni collegamenti - non puoi semplicemente scambiare i motori senza preoccuparti - ma i grandi progetti generalmente funzionano meglio quando tali cose sono minimizzate.

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

La creazione di sistemi software è molto diversa dalla costruzione di strutture fisiche. Cioè, l' implementazione è molto diversa. Mentre, ad esempio, costruisci un'enorme nave cisterna, esegui molte attività relativamente semplici (non facili!), Come saldare parti insieme da un robot o a mano, stringere tutti i dadi e bulloni, dipingere, fare la decorazione portando in tutto le attrezzature e i mobili e così via. Tutto questo è roba molto semplice da fare, davvero.

Tuttavia, quando si tratta di software, diventa molto più complesso . Ad esempio, come si implementano esattamente la parte di accesso sicura e le credenziali dell'utente che memorizzano il prodotto? Quali librerie e strumenti puoi usare? Con quali librerie e strumenti conosci? Come si scrive esattamente la funzione hashing + salting e come si garantisce che sia sicura? Puoi farlo in così tanti modi che è impossibile stabilire qualsiasi modello di progettazione pratica reale per questo tipo di cose. Sì, i suddetti modelli di progettazione non esistono su scala minore, come "best practices", ma ogni singolo sistema di software è molto diverso dagli altri, e gli avanzamenti di campo e cambiamenti a ritmo così rapido che è essenzialmente impossibile tenere il passo.

Quando costruisci una casa, non ti imbatti in tali problemi in cui ti rendi conto che i muri di supporto principali sembrano essere inadeguati e devono essere sostituiti, richiedendo di demolire i progressi finora e iniziare dalla base rifacendo i muri di supporto . Affronti tali problemi in fase di progettazione , perché è relativamente semplice prevedere quale tipo di muri di supporto sono necessari al tuo edificio.

Questo non è il caso del software. Non è possibile progettare l'intero prodotto come un'unica entità e quindi implementarlo. Il processo di progettazione del software è generalmente iterativo e gli obiettivi e i requisiti cambiano man mano che il prodotto viene implementato e testato. Lo sviluppo del software nel suo insieme è un processo iterativo in cui le cose di solito cambiano quando meno previsto, e molte volte tali cambiamenti impongono sfide che richiedono più lavoro, più complessità e, sfortunatamente e, in definitiva, più denaro, tempo e duro lavoro per ottenere il risultato giusto.

Quindi, in sostanza, il motivo per cui è difficile realizzare grandi progetti e stimare le tempistiche e le roadmap dei progetti è che lo sviluppo del software e specialmente la progettazione operativa sono campi molto complessi . La complessità è il problema principale.

La definizione di "grande progetto" è 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.
• Una calcolatrice
• Un editor di testo

Sono sicuro che stai pensando ... "ma quelli sono piccoli progetti! Un editor di testo è semplice ." Non sarei d'accordo con te. I computer sono scandalosamente complicati. Solo l'installazione e la configurazione degli utenti su un sistema operativo a volte può essere difficile e non hai nemmeno scritto il sistema operativo o costruito l'hardware.

I progetti di cui stai parlando sono progetti enormi , simili all'esplorazione dello spazio. Come fai a sapere quanto tempo ci vuole per sviluppare il viaggio inter-galattico? Su quale modello lo basiamo? Hai i noti noti, i noti sconosciuti, i noti sconosciuti e, infine, gli sconosciuti sconosciuti, che si verificano molto nello sviluppo del software.

Penso che il problema sia di aspettativa. Solo perché la tecnologia è lì non significa che usarla avrà successo (o saggio da usare) per un po '. Se altre industrie si comportassero come le industrie del software, avremmo in vendita aspirapolvere alimentati da buchi neri entro la fine del decennio. O alcuni "visionari" avrebbero le risorse per costruire una base lunare e decidere che uno Starbucks "completerebbe" davvero l'esperienza per i visitatori. Non credo che il problema sia l'industria del software, ma le aspettative riposte su di esso.

Sebbene non sia l'unica cosa che si possa menzionare, penso che valga la pena sottolineare una cosa basilare. La maggior parte dei prodotti è concepita per adattarsi al comportamento esistente. Perfino un prodotto che rappresenta una svolta radicale (ad esempio, l'auto) è generalmente costruito per adattarsi al comportamento esistente e semplicemente renderlo un po 'più semplice / facile / economico / qualunque cosa per farlo. Sì, c'è spesso qualche effetto collaterale anche sul comportamento esistente (ad esempio, ottenere carburante per l'auto invece di cibo per i cavalli), ma la maggior parte di questi tende ad essere un effetto collaterale piuttosto lieve.

Al contrario, quasi tutti i software che non cambiano il comportamento degli utenti (ad esempio, lascia che facciano il loro lavoro considerevolmente più facilmente) è sostanzialmente garantito per essere un fallimento completo dal primo giorno. Peggio ancora, i grandi progetti software non solo coinvolgono il comportamento degli utenti a livello individuale, ma il comportamento di grandi gruppi, spesso l'intera organizzazione.

In breve, la progettazione del software stesso è spesso la parte più semplice del lavoro. La parte difficile è ridisegnare il lavoro delle persone per loro. È difficile iniziare con; farlo in un modo che non solo funzionerà, ma sarà anche accettato, è ancora molto più difficile.

Airbus A380 non è stato un progetto di successo come hai menzionato. Mi capita di lavorare in una società CAD / CAM, e mi è stato detto che (avevamo anche il prioject Airbus) è stato ritardato di alcuni anni, perché utilizzavano versioni diverse di software in diverse società. Cioè, parti diverse venivano progettate in diverse parti del mondo. E mentre si sono integrati hanno capito che tutto il design non può essere integrato, quindi devono riprogettarlo in una versione. Quindi guardandolo non penso che abbia avuto successo. Se fosse arrivato 2-3 anni prima, sarebbe stato un punto di svolta per Airbus.

Anche per quanto riguarda il software robusto, guardi qualsiasi aereo, automobile (ABS, EPS, controllo del clima, ecc.) O navette spaziali che hanno oltre il 50% di software che li gestisce e mi crede che siano molto robusti. È solo che siamo più vicini al software e ci sono molti più programmi software, quindi vediamo più errori in essi.

Visita: http://www.globalprojectstrategy.com/lessons/case.php?id=23 e scopri quanto Airbus A380 ha avuto successo.

Ingegnere del software qui, con un background ingegneristico, e una moglie che lavora nella costruzione. Abbiamo avuto lunghe discussioni (e discussioni) sulle differenze del nostro lavoro.

L'ingegneria del software riguarda la progettazione di cose nuove . Quasi tutto il necessario è stato fatto da qualche parte in una libreria open source. In quasi tutti i lavori in cui un ingegnere del software viene assunto, 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 "biblioteca" 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 dedichi la maggior parte del tuo tempo a progettare un miglioramento del 10% su un'invenzione esistente, quando quello stesso tempo potrebbe essere utilizzato per 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 ogni programmatore dovrebbe modificare i progetti, hackerarli o creare qualcosa di nuovo.

Guarda indietro fino a che punto gli standard sono cambiati completamente, dall'assemblaggio in 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 è possibile continuare a migliorare i progetti di decenni fa.

La gestione del progetto è notoriamente difficile nel software . Le stime del tempo vengono eseguite meglio dalle persone che svolgono il lavoro , ma quando sono impegnate a fare stime, non scrivono codice . Ciò induce le persone a evitare qualsiasi gestione del progetto.

Spesso, molto codice dipende da persone specifiche e se queste persone sono in ritardo o non sono in grado di esibirsi, il codice non va avanti. Al contrario, se volevi costruire un'auto, puoi semplicemente assumere persone diverse per assemblare le gomme, il telaio, la batteria, il motore e così via. I framework orientati agli oggetti e quelli esistenti lo rendono possibile, ma potrebbe non essere pratico quando si progetta tutto da zero.

Gli errori possono essere consentiti nel software . Il test può essere costoso. Nel software, è molto allettante saltare tutti quei test, quando puoi semplicemente risolvere un crash. Nella maggior parte delle forme di ingegneria, un "incidente" può essere fatale.

Esistono metodi di programmazione che utilizzano test approfonditi, come la programmazione estrema (che è stata effettivamente utilizzata su megaprogetti software). Ma con scadenze strette (che possono essere rese più strette di proposito), è allettante saltare tutta quella programmazione e lanciarla 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 fallirà.

I piccoli progetti sono migliori . Mia moglie una volta mi ha chiesto di trovare un lavoro in una grande azienda. Si è concluso con una discussione secondo cui le grandi aziende sono cattive aziende ... per lei, una grande azienda aveva molte risorse, esperienza, gestione funzionale del progetto e le giuste procedure. Per me, una grande azienda è un dinosauro, dove la maggior parte del tuo tempo viene speso per riparare codice, testarlo e documentazione.

Ho visto progetti IT da un milione di dollari su cui hanno lavorato meno di 10 persone. Un numero maggiore di persone avrebbe rallentato il progetto e aggiunto una burocrazia superflua. WhatsApp è un esempio di un "piccolo" progetto che vale miliardi di dollari. Non è possibile che grandi progetti non siano possibili, ma semplicemente non servono migliaia di persone per produrre miliardi di dollari in software.

Uno dei motivi che non è stato realmente trattato nelle altre domande è che il campo del software innova a una velocità che si verifica solo raramente nel mondo dei materiali.

Uno dei motivi è che l'evoluzione del software è un ciclo di feedback positivo perché il software (linguaggi di programmazione, strumenti di creazione, IDE) viene utilizzato per costruire il software. È l'esempio più ovvio per la legge di Ray Kurzweil sull'accelerazione dei rendimenti, che porta a progressi a una velocità esponenzialmente crescente. Dopo aver imparato un framework, un linguaggio di programmazione, un protocollo di comunicazione, è tempo di passare al successivo.

Se gli aeroplani fossero costruiti come software, cambieremmo il materiale con ogni altro modello, raddoppiando la loro capacità e velocità ogni 18 mesi, sostituendo la tecnologia del motore per ogni nuovo modello con qualcosa appena inventato, aggiungendo al contempo la possibilità di nuotare e cercare extraterrestri vita.

Oh, e idealmente ascolta i comandi vocali e si raddoppia come un cinema completamente immersivo, un'arena di paintball e un night club con camera oscura al termine del viaggio di lavoro. La stessa cosa! (La società che ha costruito aeroplani che ti hanno portato in modo affidabile dalla A alla B è andata in aria un anno dopo l'uscita di quella con il cinema, il paintball e il locale notturno.)

Per me il problema principale che l'ingegneria del software deve affrontare sono i casi d'uso, utente e multipiattaforma.

Casi d'uso

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

Utente

Chi gestisce un aereo? Un pilota, un copilota, alcuni amministratori (se contati) e operatori di torri. Sono tutti professionisti e hanno le loro descrizioni di lavoro chiare. Il software viene utilizzato da nessuno e da manichini, per non parlare di hacker e cracker malvagi, ma deve comunque essere integrabile con altri moduli (come OpenID o Google AdSense ). Se un aereo può essere gestito da manichini mentre sopravvive ancora a missili o ladri ninja, allora puoi dire che l'aereo ha la stessa qualità con il software.

Piattaforme incrociate

Un aeroplano vola solo nel cielo della terra. Non sono sicuro di come gestiscano il clima nebbioso o ventoso o caldo, freddo e umido, ma un aeroplano non è progettato per volare a diversi livelli di gravitazione (rimarrò stupito se riuscirà a volare su Marte ). A volte, un'applicazione deve sopravvivere a piattaforme diverse, come Internet Explorer, Google Chrome , Firefox e Safari per browser (mi dispiace Opera ) o Windows XP / 7/8 o Linux per livello di sistema operativo. Per non parlare dei dispositivi mobili e di diverse risoluzioni e orientamenti.

Se pensi che altre industrie completino progetti senza incidenti, dovresti leggere la storia dell'edificio del 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 crollo da un evento di tempesta previsto ogni 16 anni.

In altre parole, per ogni anno in cui il Citicorp Center era in piedi, c'erano circa 1 su 16 possibilità che sarebbe crollato.

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

tutto sembrava perfetto, finché, come dice LeMessurier, ricevette una telefonata. Secondo LeMessurier, nel 1978 uno studente universitario di architettura lo ha contattato con un'audace pretesa sull'edificio di LeMessurier: che il Citicorp Center poteva esplodere nel vento.

Le riparazioni sono state fatte letteralmente nella copertina della notte coinvolgendo il minor numero di persone per mantenere il segreto del difetto di progettazione.

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

Saldarono per tutta la notte e si fermarono all'alba, proprio mentre gli occupanti dell'edificio tornavano al lavoro.

La storia è rimasta segreta fino a quando lo scrittore Joe Morgenstern ha sentito che veniva raccontato a una festa e ha intervistato LeMessurier. Morgenstern ha rotto la storia in The New Yorker nel 1995.

Il che solleva la domanda; quanti altri fatali difetti di progettazione 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)
• Citigroup Center (wikipedia.com)