Nel complesso: come manterremo i sistemi legacy? [chiuso]

NEW YORK - Con un'esplosione che fece tremare i grattacieli, un tubo a vapore di 83 anni ha inviato un messaggio potente secondo cui le miglia di tubi, fili e ferro sotto New York e altre città degli Stati Uniti stanno invecchiando e potrebbero diventare pericolosamente instabili.

Luglio 2007 Storia di un tubo di vapore scoppiato a Manhattan

Abbiamo sentito parlare del marciume del software e del debito tecnico .

E abbiamo sentito da artisti del calibro di:

• "Zio Bob" Martin - Chi ci ha avvertito " delle conseguenze del disordine ".
• Michael C. Feathers - Chi ci ha fornito una guida per "Lavorare in modo efficace con il codice legacy" .

Quindi sicuramente la comunità dell'ingegneria del software è a conoscenza di questi problemi.

Ma credo che la nostra società aggregata non apprezzi come questi problemi possano affliggere i sistemi e le applicazioni di lavoro.

Come osserva Steve McConnell :

... A differenza del debito finanziario, il debito tecnico è molto meno visibile, e quindi le persone si divertono a ignorarlo.

Se questo è vero, e credo che lo sia, allora temo che i governi e le imprese possano rinviare la manutenzione e la fortificazione regolari contro gli hacker fino a quando non è troppo tardi. [Proprio come New York e i tubi del vapore.]

La mia domanda:

• Esiste un modo per evitare l'equivalente del software di New York e i tubi del vapore?

Un problema chiave relativo al mantenimento dei sistemi legacy è la mancanza di persone che a) siano al passo con quei sistemi eb) disposti a continuare a mantenerli.

Recentemente ho posto una domanda simile a quella che riguarda i programmatori più giovani interessati ai mainframe. Il consenso tendeva al no.

Il mantenimento dei sistemi legacy è visto come un suicidio in carriera. In molte aziende in cui l'inerzia domina, gli investimenti nella formazione del personale sono scarsi per rimanere al di sopra di questi sistemi, portando a singoli punti di errore dal lato del personale. Molte persone che conosco che lavorano su sistemi simili sono alla ricerca di percorsi perché non vedono un futuro a lungo termine nei sistemi e vedono solo un danno alla carriera.

In alcuni settori, le normative sulla conservazione dei dati possono essere un fattore chiave per garantire che i sistemi legacy siano ragionevolmente sorvegliati. Questo è in particolare il problema nel settore finanziario, credo. Tali regolamenti - per quanto ne so - sono generalmente limitati nel tempo.

Tuttavia, penso in pratica, ciò che accadrà è:

Arriverà un punto nel grafico in cui il costo del passaggio a un sistema più moderno che consente di aggirare gli svantaggi di un sistema legacy scenderà al di sotto del costo di mantenimento del sistema legacy perché è più economico.

IBM sta vendendo molti mainframe al momento e stanno lavorando molto duramente per garantire che le loro grandi macchine non escludano gruppi di professionisti più giovani. Ma non penso che sia abbastanza in questa fase. Hanno alcuni USP in termini di impronta di carbonio e potenza di elaborazione effettiva.

Tuttavia, per ogni persona che acquisterà un mainframe IBM perché è possibile eseguire Linux su di esso, costa meno in termini di elettricità ed è altamente efficiente, ne avrai molti di più che sceglieranno una server farm perché hanno più familiarità con quel mondo e così sono molti più programmatori.

In definitiva molto dipende dall'industria coinvolta. Lavoro in un settore particolare che è stato molto dipendente dai mainframe per anni e anni e sono ancora ampiamente utilizzati. Ma le soluzioni ospitate stanno diventando sempre più popolari, il che consente il consolidamento delle competenze nelle aziende più grandi - questo rimuove alcune delle problematiche affrontate dalle singole società in termini di punti di errore - e inoltre, alcuni fornitori stanno osservando molto fortemente soluzioni non basate su mainframe per i problemi inerenti a quell'industria.

Quindi, in sintesi, suppongo che ciò che sto dicendo sia che, nel complesso, ci sarà un movimento verso la migrazione dai sistemi legacy non appena un punto economico di mantenimento rispetto alla migrazione diventerà a favore della migrazione. Sarà, tuttavia, in gran parte invisibile a molte persone perché non è nuovo e funky e non ha un volto molto pubblico nel modo in cui lo fa una cosa successiva. Tale migrazione può essere rivolta a fornitori di servizi o a tecnologie più recenti (in particolare laddove i fornitori di servizi sono direttamente interessati).

La mia esperienza, in particolare nelle reti, è che c'è una mossa per rimuovere la dipendenza dai sistemi legacy.

La maggior parte delle aziende ignora già il debito tecnico e non si rende nemmeno conto che le cose vanno male fino a quando non crolla letteralmente attorno a loro e le manda in bancarotta (se mai arriva a quel punto). L'ho visto davveroquello succede, e non era carino; ciò che ha peggiorato la situazione è il fatto che ho ripetutamente cercato di sensibilizzare gli imprenditori sull'aumento del debito tecnico e che avrebbe dovuto essere riparato, e ogni volta è stato respinto a causa della riluttanza a dedicare il tempo e le risorse necessarie per risolvere esso. Il risultato finale fu dopo oltre 10 anni che il sistema alla fine fallì in modo catastrofico (dopo che me ne fossi andato) e non poterono riprendersi, e fallirono, perché erano troppo stupidi per rendersi conto in quei dieci anni che spendere un po 'di soldi per risolvere il problema sarebbe stato meglio che ignorarlo del tutto. Potrei parlare per ore dell'assurda stupidità di quella compagnia, e ciò che mi ha sofferto di più è che avrebbe potuto essere evitato del tutto se i proprietari non lo fossero appena uscito per guadagnare velocemente tagliando tutto il resto.

È follemente difficile provare a dire a un'azienda se i loro sistemi sono scritti male e hanno bisogno di un pesante refactoring (se non una riscrittura totale che è normalmente il caso perché è così male). La maggior parte del tempo faranno solo tirare giù anche se li avverto che è difficile fare i cambiamenti, o aggiungere nuove funzionalità (la strada giusta, voglio dire, non solo la stratificazione di più stronzate sulla pila), o addirittura considero voi un danno al business perché vedi problemi con il sistema nel suo stato attuale.

Onestamente sono giunto alla conclusione che è una battaglia persa e che non vale la pena combattere. Le persone abbastanza intelligenti da conoscere il debito tecnico non devono essere informate due volte su di esso e sono consapevoli dei pericoli sin dall'inizio, e tutti gli altri non ascolteranno alcun tipo di motivo o avvertimento fino a quando non è troppo tardi. L'opzione migliore (e, ovviamente, la più irrealistica) sarebbe quella di far scattare la selezione naturale e far estinguere le persone ignoranti, lasciando solo quelle intelligenti. Non conosco alcun modo più pratico di gestirlo, perché tutto ciò che ho provato personalmente in passato è stato completamente ignorato, ha ridotto il mio valore agli occhi dell'azienda (per "lamentarmi") o addirittura ha provocato la mia risoluzione perché ero "troppo concentrato" sulla correzione di "ciò che non è rotto e nessun altro aveva il giusto stato d'animo per vedere che era rotto.

Le miglia di tubi, fili e ferro sotto New York e altre città degli Stati Uniti stanno invecchiando e potrebbero diventare pericolosamente instabili.

Per l'aneddoto, la stessa argomentazione fu fatta a Parigi nel 16-17 ° secolo. Sotto di essa erano stati scavati così tanti buchi e tunnel (oltre ai buchi naturali dovuti alla geologia dell'area) che un edificio occasionale si sarebbe sbriciolato.

Quando interi blocchi di città stavano crollando nel terreno, erano state date direttive per riempire i buchi e i tunnel non necessari di ghiaia e ossa (avevano anche problemi di cimitero sovraffollati). La città sopravvisse in quel modo fino a quando non fu inventato il cemento.

Il mio punto qui è che molte organizzazioni tendono ad aspettare l'ultimo minuto per eseguire qualsiasi manutenzione del software, ma i programmatori (come gli ingegneri civili) riescono a svolgere il proprio lavoro in modo rapido e corretto.

Siamo sopravvissuti al bug Y2k. Il bug Y2036 costringerà molte organizzazioni ad aggiornare il proprio hardware e software. Il mondo potrebbe finire nel 2012. Ma gli informatici non sono sociologi o critici letterari .

Oh, e come dice il proverbio nel frattempo: scrivi il codice come se il prossimo manutentore fosse uno psicopatico malvagio che sa dove vivi.

Dimentico, cosa consideriamo il codice legacy in questi giorni? Codice dell'anno scorso, codice dell'ultimo decennio o codice dell'ultimo secolo?

Il denaro guida la conversazione sul mantenimento dei sistemi legacy. Il debito tecnico assume la forma di un aumento dei costi per cambiare il sistema.

Ho lavorato con sistemi mal progettati e progettati in modo intelligente. Ciò che è interessante è che i costi per mantenerli non variano di molto. I problemi maggiori sono architetture errate per l'uso corrente, che di solito si manifestano in problemi di ridimensionamento o quando si desidera un cambiamento importante. Non converti facilmente una grande area di codice da single thread a multi-thread.

I problemi più significativi che riscontro sono i linguaggi di sviluppo utilizzati. I sistemi più vecchi sono scritti in lingue che oggi sono meno popolari, quindi devi allenarti di più o assumere risorse più stagionate (costose) e rare. In entrambi i casi, a causa del pool più piccolo, fai anche fatica a trovare individui qualificati che tendono a portare tanti problemi quante sono le soluzioni.

Per quanto riguarda la riscrittura promessa, la maggior parte dei sistemi che hanno avuto ingenti investimenti non giustifica una riscrittura. È incredibile per quanto tempo il software può essere mantenuto e migliorato. Le modifiche hardware (alcuni sistemi supportati dalla mia azienda utilizzano hardware specializzato) tendono ad essere il nostro problema più grande. La capacità di migliorare è spesso limitata solo dai meccanismi per integrare il codice legacy con nuove funzionalità.

Questo è già un grosso problema. E non mostra segni di cambiamento.

Negli anni '60 e '70 grandi istituzioni di ogni genere sono passate dalla contabilità su carta alla contabilità su sistemi informatici. In gran parte hanno scelto COBOL. La maggior parte utilizza ancora versioni aggiornate di tali sistemi COBOL. Vedi http://cis.hfcc.edu/faq/cobol per alcune statistiche al riguardo

Ogni tanto riceviamo promemoria casuali di questo, come quando Arnold Schwarzenegger scoprì un paio di anni fa che non poteva semplicemente tagliare la paga di 200.000 impiegati statali senza 6 mesi di sviluppo prima (vedi http: //www.infoworld. com / d / developer-world / californias-cobol-conundrum-067 per la verifica).

Dati i rischi del passaggio, è molto difficile giustificare la modifica di questi sistemi. Mai. Questa è stata la realtà per la mia vita. Ma non vedo alcuna ragione per questo fatto di cambiare nella vita dei miei figli. O la vita dei loro figli.

Ho amici che hanno mantenuto un codice più vecchio di loro. Ho un amico che è tornato in un'azienda 30 anni dopo aver lavorato lì per la prima volta, per scoprire che i suoi programmi erano ancora in esecuzione, invariati, in una lingua che non ricordava nemmeno!

Consentitemi di concludere con una storia vera di cosa possono accadere entrambi.

Negli anni '70, un'aziendaè stata fondata per fornire un mercato online ai trader. Il PDP-11 era un buon rapporto prezzo / prestazioni per loro, quindi lo hanno scelto. Stavano spingendo i limiti delle prestazioni di una macchina, quindi hanno scritto il loro sistema in un assemblaggio PDP-11 altamente ottimizzato. Alcuni anni dopo il PDP-11 ha smesso di essere venduto. Comunque gli affari andarono bene, le macchine durarono e le sostituzioni di seconda mano furono facili da trovare. Hanno mantenuto la loro piattaforma. Alcuni anni dopo è diventato più difficile sostituire. È stato realizzato un grande progetto per sostituire la piattaforma di trading. E 'fallito. Ci hanno provato di nuovo. E di nuovo fallito. Una delle principali cause del fallimento era che nessuno sapeva come funzionava il loro sistema di trading e nessuno poteva più leggere l'assemblea PDP-11. Quindi la salvezza colpì. Qualcuno ha creato un assemblatore PDP-11 eseguito su Linux.

Fu così che nel 2000, i commerci che entravano in un business da un miliardo di dollari l'anno andarono alle macchine Linux, su un ponte Ethernet-decnet, a emulare macchine PDP-11 che eseguivano il commercio su un sistema software che era scritto in PDP altamente ottimizzato- 11 assemblaggio. Per la velocità.

Nell'ultimo decennio non ho avuto alcun collegamento con detta società. Quindi non posso dirti se sono ancora in esecuzione su PDP-11 emulati. So che la decimalizzazione stava schiacciando dolorosamente i loro margini, quindi avevano ancora un altro sforzo per migrare. (Ho imparato la storia solo perché ho intervistato diverse persone che erano state licenziate da lì, e ho chiesto cosa fosse successo.) Comunque, dato i fallimenti precedenti, darei meglio delle probabilità persino che non abbiano sostituito con successo quel sistema.

Sembra una vera preoccupazione dal punto di vista dell'utente. Affinché la putrefazione sia ritardata, o meglio, evitata, il software in questione deve essere privo di catene. I suoi editori avrebbero dovuto liberare il codice sorgente o essere nel business di mantenere e aggiornare le fonti fino a quando il suo ultimo utente non smette di usarlo. Altrimenti, ci sono ottime possibilità che possano uscire dal mercato a causa di sacchi simili nel mondo degli affari, lasciando così il software completamente aperto ai sacchi.

Vale a dire, la durata del copyright del software e la limitazione delle licenze dovrebbe essere molto breve, al termine della quale il software e la sua base di codice entreranno nel pubblico dominio e vi rimarranno. Pertanto, consentendo all'utente di continuare ad aggiornare le fonti o assumere qualcuno per farlo, ritardando e / o evitando i saccheggi.

Oppure, se sei un po 'aperto all'idea del software libero, potresti scrivere i tuoi programmi con una licenza gratuita come AGPL o GPL o altre licenze di software libero. Da quello che ho visto, quando le fonti di un software non attirano più l'interesse degli sviluppatori a migliorarlo per qualsiasi motivo, la base delle fonti viene cannibalizzata e assume nuova vita. I pacchetti nel sistema operativo Debian tendono a seguire questo ciclo di vita, per quanto ho visto.

Avendo supportato una varietà di applicazioni governative e del settore privato, direi che la maggior parte delle aziende e almeno il governo degli Stati Uniti sono ben consapevoli dei pericoli di far marcire il codice e non rimanere al passo con le ultime tendenze della sicurezza.

Dobbiamo regolarmente ottenere il nostro software certificato per varie suscettibilità e la maggior parte dei sistemi elettronici governativi, anche quelli vecchi, ottenere aggiornamenti regolari per proteggerli.

Naturalmente ci sono eccezioni e gli hacker sono sempre in movimento, ma nel complesso penso che le persone siano abbastanza consapevoli che non puoi semplicemente lanciare qualcosa e non toccarlo mai più.

Attenzione: sarà un po 'in forma libera ...

Penso che ci siano 2 modi per esaminare la tua preoccupazione.

Se ci pensate, alcune navette spaziali e satelliti hanno eseguito lo stesso codice che li ha originariamente lanciati. D'altra parte, alcuni sono stati progettati per essere aggiornati anche se sono (molto) remoti.

Ciò che conta è l'ambiente. Ovviamente, finché non modifichi l'ambiente, il tuo codice non diventerà obsoleto. In questo caso, il codice rot non esiste davvero: il codice stesso (o il binario prodotto) non può marcire. Potrebbe rompersi se inizi ad attaccarlo da una prospettiva completamente diversa. Non è che sta marcendo, è che non si sta adattando al suo ambiente. Pensalo come un problema evolutivo.

Ma il nostro ambiente cambia. E in qualche modo, qual è la chiave del tuo problema è anche la soluzione. Il nostro ambiente cambia così rapidamente che al giorno d'oggi non ci aspetteremmo che una soluzione software non si evolva nel tempo. Trascuriamo i progetti software che non sono stati aggiornati nell'ultimo anno e ci lamenteremo del supporto di prodotti e clienti che non produce una tabella di marcia chiara. E anche quando questo funziona bene - ottieni una roadmap chiara, un buon supporto, aggiornamenti regolari ... - c'è sempre la possibilità ora che uno sfidante emergerà, con una crescita esponenziale. Spesso commettiamo l'errore di pensare che le grandi aziende affermate domineranno sempre, proprio perché dominano. Tuttavia, allo stesso modo in cui l'elemento dominante in una mandria invecchia, il software / hardware super massiccio / qualunque cosa il venditore invecchi. O solo un po 'pigro. E arriva uno sfidante che gira le cose ancora più velocemente di quanto il dominante affermato avrebbe potuto fare 5 o 10 anni prima. O il dominante prenderà semplicemente una bella botta, sopravvivendo a malapena mentre vediamo una perturbazione del mercato (economicamente parlando, con impatti su diversi campi), e poi le cose continueranno. Forse sembra imperfetto, ma di per sé è un processo organico.

Quindi, dal punto di vista dell'utente, immagino che il problema non sia così grande. La putrefazione del codice non avverrà dal punto di vista dell'utente, poiché potrà usare un'alternativa (possibilmente con una transizione / migrazione senza soluzione di continuità ... speriamo).

Ora supponendo che non stiamo vedendo le cose dal punto di vista dell'utente, o che stiamo parlando di un sistema che è immune - per ragioni sconosciute, sviluppo governativo, viaggi nello spazio, ecc ... - alla concorrenza e si suppone davvero per essere costruito per vivere / sopravvivere a lungo, dobbiamo guardare i testi a cui hai fatto riferimento. E probabilmente altra letteratura su sistemi affidabili e sistemi a tolleranza d'errore. Anche se probabilmente vogliamo spingerci oltre. Non vogliamo solo tolleranza agli errori, vogliamo sistemi evolutivi.

Il problema con l'evoluzione è che introduce cambiamenti e cambiamenti introducono punti di fallimento. Diamo un'occhiata a questi ora e cosa possiamo fare per affrontarli.

Possiamo ancora fare affidamento sulla metafora dell'infrastruttura / dell'architettura / dell'ingegneria mentre lo facciamo (dopo tutto, siamo tutti noi ingegneri del software, anche se probabilmente non c'è nulla di simile all'ingegneria del software ... per ora). C'è una ragione per cui il sistema di tubi è ancora attivo (con alcuni problemi), mentre il Big Ben funziona ancora (con alcuni problemi) o la Torre Eiffel è ancora in piedi. È perché facciamo con elementi vitali (o meno così vitali) di un'infrastruttura quello che dovremmo fare anche con il software: ispezione continua. Queste entità non sono state necessariamente progettate per durare così a lungo, ma hanno beneficiato della supervisione permanente e dei miglioramenti e riparazioni tempestivi quando necessario. Chiama i tuoi aggiornamenti rapidi, se vuoi.

D'altra parte, alcuni progetti dovevano durare e funzionare durevolmente senza interruzioni, pur sapendo che non sarebbe possibile un controllo continuo. In questo caso ci rivolgiamo a un buon design e modelli formali. Gli elementi di affidabilità (disponibilità, affidabilità, sicurezza, integrità, manutenibilità) possono essere quantificati per un determinato ambiente. Le statistiche fanno il resto per pianificare il resto e il futuro. Il che pone la domanda: è persino possibile per noi costruire sistemi che saranno evolutivi, nel vero senso del termine?

Jeff Langer in Clean Code pone una domanda simile ... senza riferimenti ai tubi del vapore:)

E se ci fossero quattro semplici regole che potresti seguire per aiutarti a creare buoni progetti mentre lavoravi? Cosa succederebbe se, seguendo queste regole, acquisissi informazioni sulla struttura e sulla progettazione del tuo codice, facilitando l'applicazione di principi come SRP e DIP? E se queste quattro regole facilitassero l'emergere di buoni progetti?

Molti di noi ritengono che le quattro regole di Simple Design di Kent Beck siano di grande aiuto nella creazione di software ben progettato.

Secondo Kent (in Extreme Programming Explained), un progetto è "semplice" se segue queste regole:

• Esegue tutti i test
• Non contiene duplicati
• Esprime l'intenzione del programmatore
• Riduce al minimo il numero di classi e metodi

Per eseguire tutti i test ... abbiamo bisogno di test da eseguire e questo è un enorme indicatore del debito tecnico. Ad esempio, se ci sono 10.000 casi di test in un sistema come il Mercury Quality Center e nessuno di questi test è automatizzato, questo è un chiaro indicatore del debito tecnico che è stato accumulato.

Ed è qui che entra in gioco Feathers e il suo libro "Lavorare efficacemente con il codice legacy".