No, il titolo non è una provocazione ma un caso reale che ti spiegherò fra poco: tu pagheresti 

un aggiornamento software 500 milioni di dollari?

 
E che cosa dovrebbe mai combinare di buono (o di cattivo!) la nuova versione di un applicativo per costare così tanto?  Ma soprattutto, come si è arrivati in soli 30 minuti a un disastro del genere in un’azienda americana, Knight Capital, che è stata sull’orlo della bancarotta per questo motivo ed è stata costretta a reperire in poche ore ingenti risorse economiche, licenziare alcuni dipendenti e vendere degli edifici di proprietà a causa di questo tracollo finanziario provocato da un software?

Come ti ho annunciato, in questa puntata andremo a sviscerare un po’ di aspetti meno noti, considerati e… poco accettati quando si va a parlare dei costi di un progetto software o comunque di un dispositivo che ne contenga, praticamente qualunque oggetto moderno oramai.

E’ tutta questione di soldi

Cominciamo con un’affermazione tanto semplice quanto sconvolgente:

IL PREZZO CHE PAGHI PER (FARTI) REALIZZARE UN SOFTWARE PESSIMO E’ LO STESSO PER UN SOFTWARE SICURO

Esatto, la produzione di un software di buona qualità, affidabile, di fatto non è di molto diversa in termini di costo iniziale rispetto a quella necessaria per realizzare un software fatto male, pieno di bug, di problemi, scarsamente affidabile. E tornerò su questo argomento a breve.

Ma il prezzo che paghi inizialmente per la realizzazione non è tutto… devi considerare altri aspetti che non sei portato naturalmente ad associare al costo del software vero e proprio, ma ad altre fasi del progetto e questo è il primo inganno di cui sei forse vittima inconsapevole ed è il caso di dipanare.

E allora dove sono nascosti eventuali costi di cui non ha tenuto conto? Come si può arrivare ad una cifra così grande come mezzo miliardo di dollari? E chi in azienda ti sta tenendo nascosti questi costi, senza farti sapere che prima o poi ci saranno, ma magari lui sarà già andato via in un altro ruolo o se non da un’altra parte?

Perché in realtà tu hai una… serpe in seno, un potenziale traditore che manda all’aria tutte le previsioni di costo dei tuoi progetti e brucia il tuo budget e nonostante questo, tu stai continuando ancora dargli fiducia. 

Evita di contrarre un debito (tecnologico)

La situazione reale è questa: in qualunque ruolo tu stia lavorando nel mondo e software, come sviluppatore, come manager di un gruppo, come imprenditore, come cliente ti sarai sempre scontrato con questa totale o quasi imprevedibilità dei costi, dei tempi, dei rischi di un progetto software. E sembra che non ci sia una soluzione, almeno così ti hanno sempre raccontato.

Basta vedere qualche numero grazie a studi effettuati su migliaia di progetti a livello internazionale: 

• Qualunque applicazione rilasciata anche dalle migliori organizzazioni mondiali contiene ancora almeno 4 errori critici ogni 1000 linee di codice
• Il 60% dei progetti software è in ritardo a causa della scarsa qualità del codice
• Il 30% è in perdita a causa di errori avvenuti dopo il rilascio del prodotto
• 500 miliardi sono stati spesi nella risoluzione di errori nel 2015

Sembra altrettanto chiaro che le tradizionali tecniche di calcolo dei tempi e dei costi basati su Project Management, diagrammi di Gantt, fogli Excel zeppi di formule per calcolare tempi e costi di un progetto software siano tutte fallimentari. C’è sempre qualcosa che sfugge a qualunque analisi e ci sono stati fior fior di teorie, di metodi, di criteri che pensavano di aver trovato una soluzione ragionevole alle stime impazzite dei progetti software, ma poche volte i risultati sono stati veramente soddisfacenti.

Si è anche dato un nome a questo fenomeno: 

DEBITO TECNOLOGICO

(Technological Debt)

Rappresentato sotto forma di un iceberg, rappresenta il rischio nascosto sotto la superficie apparentemente tranquilla, quando decidi deliberatamente di buttare sul mercato un prodotto contenente software, che sai benissimo che non è stato sufficientemente testato, ma che decidi lo stesso di fare uscire pensando poi di sistemare tutto in momenti successivi con degli aggiornamenti.

Questa volontaria assunzione di rischio non è del tutto esclusiva del mondo informatico e non è neanche del tutto sbagliata come principio: ogni giorno il manager di tutto il mondo fanno delle scelte ben precise di calcolare probabilità di un certo evento fallimentare e di proseguire lo stesso perché il calcolo costi/benefici è comunque soddisfacente o perché ci si è tutelati con un’assicurazione, delle contromisure, insomma con una strategia per contenere lo stesso rischio. 

Peccato che nel mondo del software questa cosa di fatto non sia possibile, soprattutto perché è molto difficile determinare il vero rischio di lasciare dei bug in un software che non è testato a sufficienza, perché il numero stesso dei potenziali problemi nascosti nel codice è molto difficile da calcolare. 

La vera metrica da usare (e perché nessuno lo fa)

Sai qual è il vero valore da utilizzare quando devi valutare un progetto software, ma che NESSUNA software house, fornitore, ma anche team di sviluppo ti fornirà MAI? 

Perché non è così pazza da farlo? E perché soprattutto te la tiene nascosta, addossando sulle tue spalle tutto il rischio ed il Debito Tecnologico? 

TCO (Total Cost of Ownership)

Che detto in italiano non rende benissimo, sarebbe il costo totale “di possesso” del software o meglio ancora, dell’intero ciclo di vita.

Per cui… non comprende solo la fase iniziale prima del rilascio: e quindi i classici requisiti, design, implementazione, test, integrazione. Eh no. 

Comprende pure TUTTI i costi dell’intero ciclo di vita del tuo prodotto, anche quando rimarrà in campo per anni o per decenni, con tutti i costi di conseguenza: 

• Manutenzione
• Individuazione degli errori (compresi i costi di viaggio del supporto tecnico)
• Risoluzione dei bug 
• Aggiornamenti e nuove versioni
• Rifacimenti e riadattamenti futuri

Sai qual è il problema di un costo del genere, che comprende appunto anni e anni di problemi sul campo, manutenzione, problemi, interventi? 

Ovviamente, NESSUN fornitore sano di mente ti fornirà MAI di previsione del numero e della gravità dei bug, nessun tipo di garanzia, di assistenza forfettaria, appunto di T.C.O. 

Mica è pazzo a prendersi questa responsabilità: ci pensi a dover garantire a prezzo fisso la soluzione a tutti i possibili problemi che il tuo prodotto causerà al tuo cliente, incluse le spese causate dai bug stessi?

E poi tu mica userai il suo software da solo: interagirà con altre librerie, con il tuo hardware, con altri dispositivi… come fa a garantirne il funzionamento corretto e la soluzione dei problemi per decenni? Semplice: non lo farà MAI. 

E visto che questo costo non se lo accolla lui, cosa farà?

 
Semplice: lo addosserà a te e alla tua azienda!

Ma abbiamo solo spostato il problema: tu sei il cliente, il committente e il tuo fornitore ti ha consegnato un software di cui non conosci la qualità vera perché non hai metriche, non sai quanti bug contiene, quando verranno fuori e il loro impatto futuro. Insomma: ancora una volta non sai (o non vuoi sapere) il tuo T.C.O. (Total Cost of Ownership). 

E allora indovina cosa succede? Visto che nessuno sa come prevederlo, come provare a limitarlo, come assicurarsi contro i potenziali rischi? 

Qual è, per citare il tema della newsletter, “Quello che le aziende software non dicono”? 

Il fatto che il TCO 

E’ IGNORATO DELIBERATAMENTE AL MOMENTO DELLA REALIZZAZIONE

Esatto: il tuo manager, il tuo responsabile al momento di valutare il costo di un software, non si metterà MAI a fare previsioni rischiose, impossibili, imprevedibili e preferirà NASCONDERE TUTTO.

Tanto… nessuno gli chiederà mai conto tra 5, 10 anni di grandi problemi, crash disastrosi, se non addirittura morti o feriti causati da software Safety Critical. Lui molto probabilmente se ne sarà andato… avrà fatto carriera, si sarà spostato di progetto se non addirittura di azienda.  

Basta che la sfanghi i primi anni, metta a posto i primi problemi (che comunque rimangono sempre fuori dalle stime iniziali: hai mai sentito qualcuno che prevede i bug iniziali della cosiddetta “Mortalità infantile” di un software? Io non credo. 

Eccolo il Giuda aziendale: quello che fa semplicemente finta che il costo del ciclo di vita completo del software, il TCO, sia solo quello di sviluppo e rilascio aziendale. Quello che ignora l’iceberg del Titanic anche se sa che c’è e non si premura di capire dov’è e quanto è profondo. Quello che sarà già al sicuro quando la nave si schianterà. 

E veniamo finalmente a… 

Il disastro da mezzo miliardo di dollari

Veniamo a questo punto al tracollo finanziario che ha afflitto Knight Capital nel 1998 e ha causato 500 milioni di perdite in Borsa per colpa di… un banalissimo aggiornamento software!

Il 1 ° agosto 2012, Knight Capital ha causato una grave interruzione del mercato azionario che ha portato a una enorme perdita commerciale per l’azienda. L’incidente è accaduto dopo che un tecnico ha dimenticato di copiare il nuovo aggiornamento Retail Liquidity Program (RLP) in uno degli otto server SMARS, il sistema di routing automatico di Knight per gli ordini azionari. 

L’aggiornamento RLP ha riutilizzato un flag precedentemente usato per attivare una vecchia funzione conosciuta come “Power Peg” che era stato progettato per spostare i prezzi delle azioni sempre più in alto per verificare il comportamento degli algoritmi di trading in un ambiente controllato.  

Codice morto, in pratica, che NON DOVREBBE ESSERE PRESENTE PER DEFINIZIONE!

A causa del mancato aggiornamento dell’ottavo server, gli ordini inviati con il flag modificato hanno attivato il codice Power Peg difettoso ancora presente su quel vecchio server. Una volta rilasciato in produzione, le attività commerciali di Knight hanno causato un grave turbamento dei prezzi di 148 società quotate alla Borsa di New York.  

    
Ad esempio, le azioni di Wizzard Software Corporation sono passate da $ 3,50 a $ 14,76. Per 212 ordini in arrivo che sono stati elaborati dal codice Power Peg difettoso, Knight Capital ha inviato milioni di ordini figli, ottenendo 4 milioni di esecuzioni in 154 titoli per oltre 397 milioni di azioni in circa 45 minuti.    

  
Il CIO (Chief Information Officer) dell’azienda è stato chiamato in fretta e furia dai broker finanziari preoccupati per l’insolito volume di vendite, ma 

non aveva preparato un piano di emergenza per casi simili e nessuno aveva idea di cosa fare

per cui hanno istintivamente scelto la soluzione che si è rivelata peggiore: 

hanno messo la vecchia versione su tutti gli 8 server, moltiplicando di fatto la gravità del problema. 

 
Solo dopo oltre mezz’ora i server sono stati disattivati ma nel frattempo il disastro era stato fatto. 

Knight Capital ha subito una perdita di $ 440 milioni. Ciò ha causato il crollo del prezzo delle azioni, con l’effetto di scendere di oltre il 70%. La natura dell’attività di trading insolita del Knight Capital è stata descritta come una “catastrofe tecnologica”. 

Domenica 5 Agosto la società è riuscita a raccogliere circa $ 400 milioni in fretta e furia vendendo asset e immobili nel tentativo di rimanere in attività dopo l’errore commerciale.   

Di chi è la colpa?

Secondo te la colpa… è di quel povero tecnico che non ha aggiornato l’ottavo server?

Evidentemente NO! La colpa è in realtà è di chi ha progettato non tanto il software, ma la procedura di aggiornamento che aveva gravissime ed evidenti lacune.

Come minimo: 

• ci doveva essere un secondo tecnico indipendente che facesse un controllo aggiuntivo sulla coerenza delle versioni di tutti i server
• l’aggiornamento avrebbe potuto essere automatico con un controllo finale sulla coerenza della versione dei vari software
• il sistema alla partenza poteva e doveva controllare che tutti i server parlassero lo stesso linguaggio, sincronizzati sulla stessa procedura, altrimenti segnalare un errore e bloccarsi
• inoltre, a monte, non si riutilizzano flag così senza un Risk Assessment, e non si lasciano pezzi di codice morti non più utilizzati, che andavano rimossi da tempo
   

 Come vedi, come in tanti incidenti aerei ferroviari e simili, il problema non è mai quello più evidente come l’errore umano, Ma è un errore di progettazione che sta alla base e che è frutto di leggerezza, ignoranza, trascuratezza dei rischi.

Adesso ti faccio alcune domande retoriche, di cui so già la risposta…

Qualcuno aveva previsto questa eventualità?
Qualcuno aveva preso delle contromisure?
Qualcuno si era reso conto del potenziale pericolo di un software così delicato?
Ma soprattutto, secondo te chi aveva commissionato questo software aveva considerato la probabilità di un evento del genere? E l’impatto sui costi? 
Aveva dato un valore a questo rischio? L’aveva assicurato?

E L’azienda che ha realizzato questo software questa procedura, aveva dato qualche forma di garanzia dai guasti? Qualche assicurazione sulle conseguenze? Aveva realizzato un programma con tutte le caratteristiche che avrebbe richiesto un programma così delicato? Aveva avvertito il committente dei possibili rischi e contromisure?

Vi rendete conto che, in questo caso sicuramente limite, il TCO reale di questo software è come minimo 1000 se non 10000 volte più alto del costo iniziale che è stato pagato?

Perché gli approcci proposti finora non funzionano 

 Tutti gli approcci dello sviluppo software finora proposti, da quelli snelli e moderni come AGILE fino anche alla Certificazione Avionica Safety-Critical DO-178, per quanto presentino degli aspetti sicuramente molto interessanti, non sono del tutto adatti a contenere la problematica del debito tecnologico.

Metodo AGILE

 E’ diventato il metodo più celebre di produzione del software, almeno a livello di nome, superando di popolarità il vecchissimo Waterfall o il moderno Ciclo a V. 

Ma… è veramente conosciuto nei dettagli o solo di nome o peggio ancora di fama? 

E che fama ha… ne hai sentito parlare in termini polarizzati, quindi o troppo entusiastici o troppo drammatici? 

La verità come sempre sta nel mezzo: il metodo AGILE si propone come approccio… appunto agile al mondo complesso e mutante dello sviluppo software, in contrapposizione a quello ingessato e pesante del Waterfall ma tende a essere poco adatto ad approcci rigorosi e critici. 

In parte, con l’approccio DevOps (di cui parlerò in seguito), potrebbe in parte risolvere il problema del rilascio del software (e avrebbe aiutato la Knight Corporation a non perdere 500 milioni di dollari in 30 minuti) ma non è sufficiente per contenere i costi di lungo periodo.

Buona parte dei principi sono molto validi, di sicuro hanno un fondamento molto utile ma magari si perdono in contraddizioni che vogliamo evitare, oppure danno troppa poca importanza a certi aspetti fondamentali quando si vuole usare un approccio scientifico e ingegneristico al software, che sia nello stesso tempo agile come il metodo stesso vorrebbe.  

Perciò, con cautela e qualche eccezione… possiamo abbastanza applicarli con cura.

Certificazione Avionica DO-178

Vediamo ora invece la parte della certificazione avionica, che fa molta più paura (da fuori) per la sua rigidità e per i suoi costi, ma che come vedremo ci darà in cambio una serie di enormi vantaggi anche per la tua azienda… anche se sviluppi software del tutto innocuo (per le persone) ma non per il business altrui (e quindi di conseguenza anche per il tuo!).

La certificazione avionica è in assoluto la più temuta: considerata alla stregua delle forche caudine, è considerata terribile e dispendiosa, non a torto direi. Il budget di un progetto “normale” certificato con standard diversi o addirittura non certificato, può lievitare anche del 200 o del 300% se l’azienda volesse procedere lungo il  percorso della DO-178, senza tra l’altro nessuna garanzia di riuscita e soprattutto con una difficile gestione e previsione dei tempi.  

Qual è la contro-partita?  

Bene: 

NEL 2017, NON C’E’ STATO NESSUN INCIDENTE MORTALE CON AEREI DI LINEA. NESSUNO!

Ma a parte che questo ci fa ovviamente molto piacere, l’aumento dei costi  dello standard avionico è un fattore di cui tenere conto, da bilanciare però con quelli di lungo periodo.    

Per cui… l’apporto che può dare la Certificazione Avionica sulla qualità, stabilità, affidabilità del codice è notevole, ma l’impatto sui tempi e sui costi rimane un punto debole. 

Approccio M.E.D.S (Method for Efficient Development of Software) 

 Con il M.E.D.S. invece puoi riuscire a trarre vantaggio da tutto questo: 

• sfruttare a tuo personale vantaggio i punti salienti della certificazione avionica DO-178
• applicare i principi fondamentali in un ambiente safety-critical non avionico o anche solo business-critical
• lasciar perdere tutta la burocrazia, attività ridondanti e inutili per la tua azienda
• ottenere un incremento incredibile della qualità del tuo software a fronte di un piccolo investimento nel processo di sviluppo
• risparmiare alla fine un sacco di soldi considerando tutto il ciclo di vita compreso supporto e assistenza sul campo

Ecco, abbiamo quindi visto come da questi due metodi, normalmente applicati in uno specifico contesto non sempre applicabile, possiamo tranquillamente estrarre alcuni principi ispiratori, alcune tecniche e metodologie che sono applicabili in qualunque ambito, anche non certificativo 

conservando la flessibilità e scalabilità del metodo ma nello stesso tempo un necessario rigore 

Come tenere conto del TCO (e suddividerne il rischio) 

  Il T.C.O. (Total Cost of Ownership) si può prevedere, ridurre, si possono organizzare le attività fin dall’inizio per attutire la probabilità di eventi come quelli di Knight Capital, si possono riconoscere i problemi in anticipo, attenuarne le conseguenze, calcolarne le probabilità e gestirli. 

Bisogna tanto per cominciare spostare la Qualità al Giorno Zero, come spiego nell’intervista apparsa sulla prestigiosa rivista Aerospace Testing International: 

 
SS – Aerospace Testing International – Interview about Software Testing

Per fare questo, il modo migliore è adottare un metodo di lavoro come il M.E.D.S (Metodo per lo Sviluppo Efficiente del Software), che si basa sullo standard avionico DO-178 ma che ne armonizza e fluidifica gli aspetti più duri e rigidi con quelli efficienti dell’AGILE, con il risultato di avere:

il T.C.O. più basso tra tutti gli altri approcci finora esistenti

Conclusioni

Ti è piaciuto questo articolo? Scopri la mia newsletter gratuita dove periodicamente troverai:

• analisi dettagliate di incidenti critici (apparentemente) causati dal software
• strategie ottimali per produrre software Safety- e Business-Critical
• consigli su come adottare delle tecniche sicure ed efficaci nei tuoi progetti

Lascia la tua email per avere immediatamente accesso alla mia newsletter:

E sarò lieto di aiutarti a capire come tenere lontani i vecchi col cappello dal tuo progetto software…

Massimo Bombino