Come posso convincere il management a gestire il debito tecnico?

Questa è una domanda che mi pongo spesso quando lavoro con gli sviluppatori. Finora ho lavorato in quattro società e sono venuto a conoscenza della mancanza di attenzione nel mantenere pulito il codice e gestire il debito tecnico che ostacola i progressi futuri in un'app software. Ad esempio, la prima azienda per cui ho lavorato aveva scritto un database da zero anziché utilizzare qualcosa come MySQL e questo ha creato l'inferno per il team durante il refactoring o l'estensione dell'applicazione. Ho sempre cercato di essere onesto e chiaro con il mio manager quando discute delle proiezioni, ma il management non sembra interessato a sistemare ciò che è già lì ed è orribile vedere l'impatto che ha sul morale della squadra.

Quali sono le tue idee sul modo migliore per affrontare questo problema? Quello che ho visto è la gente che fa i bagagli e se ne va. La società diventa quindi una porta girevole con gli sviluppatori che entrano ed escono e peggiorano il codice. Come lo comunichi al management per renderli interessati a risolvere il debito tecnico ?

Quando ho incontrato il mio capo per discuterne, mi ha detto che avrei dovuto includere il refactoring in tutte le mie stime. Ha detto che non è un problema a cui vuole pensare. Invece, dovrei gestirlo.

Questo non è un problema a cui la direzione in generale vuole pensare. Non sono gli ingegneri, lo sei. Rendi solo questa una parte inespressa di tutte le tue stime e scoprirai che il debito tecnico diminuisce.

Non sarà mai perfetto però. Il debito tecnico, come il debito della carta di credito, è un investimento per rendere i clienti più veloci e ottenere una quota di mercato più rapida rispetto alla concorrenza. Come il credito, se gestito correttamente, può farti abbastanza successo.

È come ha detto Gandhi quando gli è stato chiesto se la sua tattica avrebbe funzionato con qualcuno come Hitler. Disse: "Sarebbe difficile". Ma penso che ci sia una buona argomentazione secondo cui la risposta è davvero "No". Purtroppo, non penso che ciò che stai cercando di fare possa essere fatto. Non è che sto cercando di essere pessimista, ma piuttosto sto cercando di essere onesto.

Il problema per me non è che i manager debbano convincere. I migliori comprendono già che il debito può essere un killer se non gestito. Ma che lo capiscano o no, che siano bravi manager o cattivi, tutti affrontano la pressione di consegnare e quella consegna viene giudicata dai loro capi in base a una data. La qualità conta solo se è estremamente negativa, nel qual caso è colpa degli sviluppatori, o estremamente buona, nel qual caso è la genialità del management che l'ha resa possibile. La qualità deve solo essere "abbastanza buona".

Penso che mi piace quello che Renesis ha detto nella sua risposta, perché è uno dei pochi a capire che il management pensa in modo molto diverso dall'ingegneria. E penso che tutti noi abbiamo visto la progressione delle aziende diventare orientate alla data e più gestite dal progetto rispetto al cliente e alla qualità. Con questo intendo le aziende tipiche, non quelle veramente sgarbate che hanno il coraggio di dire "Sarà fatto quando sarà fatto" (come Apple Computer o Software id - e sì, capisco che a volte le persone non sono libere per adottare questo approccio).

Ma ecco il punto: le aziende che adottano il primo approccio di qualità ... cosa noti di loro? Esatto, sono gestiti da ingegneri, non da venditori, esperti di marketing, project manager o commercialisti. Pensa a HP, Apple, id, Google, Microsoft e IBM. Tutto è iniziato e realizzato con successo dagli ingegneri, non dai venditori, anche se i venditori hanno sicuramente giocato un ruolo, e sono sicuro che molti avrebbero discusso del fatto che Microsoft fosse associata alla qualità :). E di quelli, quelli che sono andati in discesa si sono allontanati dalla leadership guidata dall'ingegneria. Ci sono molti argomenti in questa affermazione, dato che ci sono molte aziende tecniche che alla fine hanno fallito a causa dell'incapacità di adattarsi ai tempi che cambiano e gestire la propria crescita. Non vedo la leadership basata sull'ingegneria come la causa di questi fallimenti, secondo me " s un problema di capacità e acume aziendale che sono indipendenti dal fatto che qualcuno sia uno sviluppatore o un contabile. Penso in generale, tuttavia, che ci sia una dedizione in ingegneria ai rigori della responsabilità e della disciplina che avvantaggia le aziende in cui l'ingegneria è una componente.

Seriamente, guardati intorno. La leadership IT è gravemente carente. L'attenzione è sempre sui costi e sui tempi, e raramente sulla qualità, purché sia ​​abbastanza buona. I leader IT raramente riferiscono più al CEO, ora è sempre il CFO. L'IT è bloccato nel supportare la produzione e sempre di più nei confronti dei project manager che si concentrano su blocchi più piccoli, più digeribili e misurabili, non cambiamenti significativi di valore rivoluzionario (non che ciò sia necessariamente sbagliato; dividere e conquistare è una buona cosa, ma la visione deve essere lì per il quadro generale).

Mi spiace occuparmi così tanto di questo post, ma alla fine penso che la tua domanda, su come attirare l'attenzione del management sul debito tecnico, sia spesso risolta meglio trovando il leader giusto, piuttosto che cambiare quello esistente. Spiegare il debito tecnico verso i pensatori standard significa cambiare l'attenzione su denaro e costi, come ha detto Renesis, e penso che perda molto nella traduzione; anche se ci riuscissi, importerebbe solo se lo acquistasse il miglior leader dell'azienda. Convincere il tuo middle manager a fare la cosa giusta probabilmente lo farà licenziare.

La prima cosa da fare è cambiare il testo. Chiamarlo "debito tecnico" dà al management l'idea che consentirlo sia un investimento di qualche tipo, quando in realtà è più simile a un virus. (Sono come il Dave Ramsey del debito tecnico.)

Permetterlo di non essere pagato ha un costo enorme che non può essere visto o facilmente quantificato.

Elencare i problemi come i seguenti per la gestione:

• Le stime delle nuove funzionalità sono molto più elevate di quanto debbano essere. O, impossibile del tutto.
• Il codice errato genera altro codice errato
• L'elenco dei bug cresce anche se gli sviluppatori li risolvono sempre
• I membri del team se ne stanno andando (questo stesso può dimostrare che c'è un problema, come spiegato in questa risposta eccellente )

Il mio management ha effettivamente iniziato a fare uno sforzo serio per affrontare il debito tecnico, che è uno dei motivi per cui mi piace lavorare lì, ma è uno sforzo a lungo termine e non fa mai male ricordare loro perché lo sforzo vale la pena.

Un modo per mantenere la pressione è quando mi viene chiesto un preventivo e, se non dovessi occuparmi di specifici problemi di debito tecnico, avrei potuto risparmiare tempo, includendolo nel mio preventivo . Ad esempio, " Questo bug richiederà 2-3 giorni per rintracciarlo, ma se avessimo già risolto questi altri 2 bug" a bassa priorità "che sono stati in coda per sempre, probabilmente ne occorrerebbero meno di uno. " Spesso, la risposta sarà di andare avanti e sistemare gli altri mentre ci sei.

Concordo anche con altre risposte riguardo al considerare i miglioramenti come parte del tuo lavoro e a farli come fai se non sono troppo distruttivi. Il mio compito attuale prevede l'aggiunta di alcuni codici molto mal progettati. Invece di aggiungere al caos scrivendo il mio nuovo codice per abbinarlo, sto impiegando un po 'di tempo a consolidare le funzionalità comuni, quindi l'invio di un pacchetto diventa una chiamata di funzione a una riga invece di ripetere costantemente 15 righe di copia e modifica leggermente modificate incolla il boilerplate.

So per certo che salverà ulteriormente la sanità mentale di un manutentore lungo la strada. Lo so perché sono quel manutentore oggi. Tuttavia, credo anche che acceleri il mio attuale compito di attivare questa funzionalità e eseguire il debug ora.

Un'altra tecnica che ho usato in passato e che dovrei fare di nuovo è quella di mantenere un ramo DVCS refactoring in giro in un albero di lavoro separato per quel tempo di inattività durante la compilazione, in attesa di un lungo test o solo bisogno di un cambio di ritmo per un po 'quando sei stanco di un bug. Fintanto che occasionalmente ti unisci a monte in modo da non divergere troppo lontano, puoi impiegare tutto il tempo che desideri sul refactoring delle modifiche con uno sforzo marginale molto ridotto. 15 minuti qua e là al giorno possono davvero aumentare nel tempo.

Potresti provare l'analogia con la carta di credito. Chiedi loro "ti senti a tuo agio nel lasciare gli estratti conto della tua carta di credito non pagati per un lungo periodo di tempo?"

I gestori comprendono costi e benefici, ma (di solito) non i termini tecnici utilizzati da noi sviluppatori. Il termine "debito tecnico" è già stato inventato per aiutare a superare questa barriera di comunicazione, ma potrebbe essere necessario articolarlo più chiaramente. La maggior parte dei gestori sa molto bene (spesso per esperienza personale) che i pagamenti scaduti con carta di credito crescono con un tasso di interesse orribile, quindi fa male lasciarli non pagati. Questo può aiutarli a ottenere la gravità del problema relativo all'entropia del software.

Ma se ciò non li convince, prova a raccogliere prove concrete e fai dei calcoli. Ad esempio, quanto costa per l'azienda, sia in termini di liquidità che di perdita di tempo, sostituire un dipendente uscente.

Nessuno darà soldi per sostituire qualcosa che funziona con qualcos'altro che (con un po 'di fortuna) funziona anche.

Quello che puoi fare è proporre di sostituirlo con qualcosa che fa di più, cioè raggruppare il servizio del debito tecnologico in un aggiornamento che porta vantaggi aziendali immediati e tangibili.

Ovviamente dovresti essere aperto al riguardo, non stiamo parlando di "intrufolarlo" in un nuovo progetto qui.

Trovo l'altro lato, quello degli sviluppatori più difficile da gestire. Fondamentalmente si riduce a questo: per alcuni sviluppatori, assicurarsi che il proprio codice sia il miglior codice possibile è una questione di orgoglio professionale. Per altri, questo è solo un altro lavoro e l'obiettivo è farlo in fretta e tornare a casa.

Nessun dato convincente cambierà questa situazione, e se introduci uno standard di qualità del codice obbligatorio, i tuoi sviluppatori da nove a cinque troveranno un modo per far funzionare il sistema, mentre i tuoi sviluppatori dedicati saranno inevitabilmente infastiditi da tutta la procedura (che non è non sono rivolti a loro, ma non puoi dire che lo sviluppatore X deve obbedire alle regole, mentre Y può fare quello che vuole).

Ciò che funziona, ma può ancora essere molto frustrante, è avere i tuoi sviluppatori più dedicati e competenti a supervisionare la base di codice, probabilmente un buon compromesso tra andare avanti e riordinare ciò che è alradie lì.

Il fatto è che in molte aziende, in particolare data l'attuale situazione economica, ogni ora deve essere fatturata a qualcuno.

Oppure scendono veloci .

A meno che i clienti esistenti non siano disposti a pagare per il refactoring, il che è profondamente improbabile a meno che non si tratti di prestazioni o funzionalità notevolmente aggiornate. Quindi non accadrà sulle basi di codice più vecchie. Potresti essere in grado di intrufolarlo nel budget per i progetti più recenti, se i clienti hanno tasche profonde, ma a meno che non sia necessario modificare le API nel refactoring, non sarà utile ai progetti più vecchi e potrebbe anche introdurre un situazione in cui la società supporta due basi di codice, che provoca ulteriori mal di testa e costi.

Come ingegnere, mi piacerebbe riformattare il vecchio codice, che non è più veramente adatto allo scopo, ogni volta che qualcosa diventa obsoleto o deprecato. Ma come i miei MD in tutte le aziende in cui ho mai lavorato mi hanno detto: "Chi pagherà?"

Cerco sempre di pulire mentre vado. Non ho finito finché il codice non è pulito. Il problema con il debito tecnico è che la maggior parte delle persone non lo capisce. Il modo migliore per affrontarlo è di non accumularne nulla. Se i tuoi manager si affidano ai tuoi sviluppatori per decidere come risolvere un problema, puoi rendere l'igiene del codice parte di ogni attività di programmazione. Se non si verifica mai un codice errato, non si accumula debito. Se segui anche la regola del boy scout (lascia sempre il codice più pulito di quello che hai trovato) il tuo debito esistente svanirà lentamente.

Non vedo il refactoring come un'attività separata dall'implementazione delle funzionalità. È parte integrante di esso.

Se hai a che fare con manager non tecnici, sarebbe di aiuto se riuscissi a trasformare la discussione in termini comprensibili. Se riesci a costruire un caso realistico per un ROI positivo sul lavoro speso per estinguere il debito tecnico, potresti arrivare da qualche parte. L'esercizio dipenderà dalle tue circostanze, ma un esempio potrebbe essere qualcosa del genere:

Analizzare il tempo che gli sviluppatori sono costretti a dedicare per aiutare il supporto con problemi di produzione, quindi ipotizzare che la correzione del vecchio codice scadente A. ridurrebbe il numero di problemi di supporto, B. renderebbe più semplice per il supporto risolvere i problemi senza passare allo sviluppo e C. ridurre il tempo che lo sviluppo dedica ai problemi di produzione quando si presentano. Per dirla in termini di dollari risparmiati dal fatto che gli sviluppatori non siano collegati per fare il lavoro di supporto. Sottolinea inoltre che ogni ora che uno sviluppatore spende facendo il supporto è un "doppio scemo" perché non solo stai pagando uno sviluppatore per fare il supporto, ma stai bruciando il costo opportunità di ciò che potrebbe fare lo sviluppatore (aggiungendo nuove funzionalità, ecc. .)

Sì, alcuni dei numeri saranno voodoo / fumo-e-specchi ... va bene, il sporco segreto del management è che sanno che la maggior parte dei numeri che usano sono BS totali, basta che tu dia loro qualcosa apparentemente concreto con cui lavorare, in modo che possano prenderlo in testa, hai una possibilità di combattere.

Dopo questa spiegazione del debito tecnico, la tua direzione dovrebbe essere convinta a ripagarlo:

Immagina di avere una cucina molto sporca piena di merda. Prima di preparare un pasto, devi prima passare un'ora a pulire. Ed è così ogni volta che vuoi mangiare. Inoltre, quando prepari un pasto, devi essere molto attento, per assicurarti che la merda non cada nel tuo pasto.

La cucina è il tuo codice, il pasto è il tuo prodotto e mangiare è vendere il tuo prodotto.

Se possono permettersi di aspettare più a lungo per l'implementazione di una modifica, senza una rete sicura di unit test, allora c'è qualcosa che non va nella tua azienda.

Deve essere un argomento molto convincente, in termini di prodotto originale e business case, che non potrei usare quei soldi ora per fare qualcosa di più importante per me. Piaccia o no, la tua direzione o i tuoi clienti pagano per questo e devi essere in grado di vendere per convincerli.

Riformuliamolo per posizionarti come cliente. Buon vecchio gioco di ruolo.

Supponiamo che tu stia comprando un frigorifero. E potresti comprare un frigorifero per $ 1000 che funzionava bene da Acme Corp. O un frigorifero per $ 2000 da Acme Deluxe Fridges che sembrava lo stesso all'esterno e aveva le stesse specifiche tecniche, ma aveva costi di manutenzione inferiori a causa di un'architettura interna più pulita.

Come cliente, quale compreresti tu stesso?

E cosa pensano gli ingegneri di Acme Deluxe la risposta migliore?

Il " debito tecnico " può essere un argomento difficile da presentare alla direzione in quanto potrebbe non vederne la necessità. La domanda potrebbe essere formulata come se nella società ci sia o meno un campione che affermi "Guarda, stiamo impiegando il X% del tempo per lavorare sul debito tecnico qui. Dacci 3 mesi per mostrarti che funziona bene" o qualcosa del genere simile. C'è una pretesa di autonomia lì, ma anche un lasso di tempo, altrimenti il ​​management potrebbe chiedersi per quanto tempo prima di vedere alcuni risultati che è piuttosto pericoloso.

Il primo punto è se vedono o no questo come un problema. Se la persona con problemi di vista non sa nulla degli occhiali e quali tipi di cambiamenti possono apportare, come possono capire perché un esame della vista potrebbe essere prezioso? Stessa idea qui in cui l'argomento è piuttosto tecnico e purtroppo non facilmente quantificabile.

Dovresti smettere di lamentarti.

Ecco perché:

1. Non prevedono mai di utilizzare il software per più di un anno
2. è solo una perdita di tempo modificarlo se il loro piano è quello di scaricarlo in seguito
3. ci sono alcuni problemi reali che devono essere risolti ora
4. i programmatori devono solo imparare a gestire la manutenzione, anche se non è sempre divertente
5. lamentarsi di sapere meglio ciò che deve essere fatto è arrogante: qualcun altro prende la decisione e dovresti esserne felice
6. Si fidano comunque che tu scriva un buon codice

Quindi il modo migliore per procedere è:

1. Quando ti danno una nuova attività, prova a implementarla nel miglior tempo possibile
2. Scrivilo perfettamente la prima volta. Se in seguito è necessario modificarlo, la prima volta si è commesso un errore e ogni cambiamento va sempre nella direzione sbagliata - ed è un'opportunità di apprendimento per i programmatori quando si commettono errori.
3. Non chiedere altro tempo, non lo capirai, ci sono delle scadenze che conosci.

Presumo che tu non sia mai stato coinvolto in un progetto di riscrittura / sostituzione o persino aggiornamento e sistema esistente.

Questi sono alcuni dei progetti più difficili da completare con successo. Alcuni dei problemi che incontrerai sono:

1. Le regole aziendali si perdono nel tempo.
2. La documentazione e l'implementazione sono totalmente fuori sincrono.
3. Quello che vedi come un bug gli utenti vedono come una funzionalità.
4. Al contrario, molte "funzioni" verranno visualizzate come difetti dagli utenti.
5. Non otterrai acquisti da parte degli utenti - considereranno la tua "scoperta di fatti" come "secchioni che fanno domande stupide", considereranno lo sforzo di test come una perdita di tempo, insisteranno sull'aggiunta di nuove funzionalità in modo da allungare un progetto essere già in ritardo.
6. È probabile che il codice sorgente non corrisponda al 100% all'eseguibile in esecuzione.
7. Mentre il tuo dipartimento si sta occupando dello sviluppo del refactoring, il business che in realtà vuole non viene svolto.
8. È probabile che il tuo re-factoring comporterà "interfacce migliorate più pulite", trascinando così altri progetti nel tuo pantano di consegna ritardata e test falliti.
9. Dopo che il progetto è stato fissato (ben oltre il 50% di questi sforzi fallisce completamente) avrai perso tutta la credibilità - dovrai trasferirti in un'altra società in un'altra città per trovare qualcuno disposto ad ascoltare anche te.
10. Se il progetto "avrà successo" tutti ricorderanno che incubo è stato - lo farai .......

Vi esorto a evitare eventuali riscritture / progetti di refactoring come la peste, possono essere alcune delle esperienze più scoraggianti nella carriera di qualsiasi professionista.

C'è molta saggezza nella frase "Se non è rotto non aggiustarlo".

Per la mia vita non riesco a capire perché alcune persone abbiano così ciecamente paura del cambiamento - sa di mancanza di fiducia nelle tue capacità.

Ho visto uno spettacolo ieri sera sul Parco Nazionale di Yosemite ed è stato osservato che dal 1940 alla fine degli anni '90 non è spuntato un nuovo albero di Sequoia. Si è scoperto che il motivo era che esisteva una rigida politica contro la combustione degli incendi boschivi e che le pigne di sequoia avevano bisogno del calore del fuoco per aprire e rilasciare i loro semi.

Vedi, un incendio ogni dieci anni circa era salutare. Ha eliminato tutto il deadwood e il rovo accumulati per mantenere in salute gli alberi (processi) esistenti e fare spazio a quelli nuovi (caratteristiche).

Sono su un progetto in questo momento che ha un chiaro caso di ricostruzione: il software legacy è stato scritto interamente utilizzando i moduli web .NET. Quasi tutta la logica aziendale è combinata con la logica di visualizzazione tag HTML / server e non può essere estesa ad altre applicazioni ora che l'azienda è cresciuta.

La gestione è alla base del compito perché hanno un'adeguata fiducia nei loro sviluppatori che, mi rendo conto, è un lusso raro.

Sì, chiediti se una ricostruzione è veramente necessaria. Fai del tuo meglio per riutilizzare il codice esistente che funziona dove puoi. Integrare quel codice nella ricostruzione, se necessario. Non permettere a nessuno di convincerti che avere paura di apportare modifiche audaci sia l'unico modo per esistere come sviluppatore di software.

In bocca al lupo!

È necessario fornire alla propria direzione un motivo finanziario per far fronte al debito tecnico e un quadro per la gestione della riduzione di tale debito tecnico.

Mantenere una tabella di marcia tecnologica è uno di questi quadri. Iniziare con una tabella di marcia ti aiuterà a impedirti di accumulare debito tecnico e può anche aiutarti a ridurre il debito esistente.

Molti progetti a lungo termine di successo hanno associato comitati direttivi e tabelle di marcia per guidare lo sviluppo. Questi sono particolarmente utili quando sono coinvolti più team di sviluppo e parti interessate.

Il mio suggerimento è di discutere questa strategia con i vostri manager (e, se possibile, con quelli che prendono decisioni su dove vengono spesi i soldi).

L'approccio generale alla creazione e alla gestione di una tabella di marcia è semplice, ma richiede il supporto del team di gestione. Innanzitutto, definisci un obiettivo. Definire gli elementi del debito tecnico e sviluppare un'architettura di sistema target che riduca gli elementi del debito tecnico. Ricorda, non deve essere perfetto, realizzabile e migliore di quello che sei attualmente. Prendi in considerazione software, strumenti di sviluppo, piattaforme hardware, nuove importanti funzionalità che possono essere aggiunte al sistema. Fai un'analisi dei costi. Se si dispone dell'architettura desiderata, quali sono i vantaggi tangibili dell'esecuzione del refactoring? (I vantaggi includono tempi di test ridotti, prodotti software più affidabili, cicli di sviluppo più prevedibili, ecc.) Se si possono dimostrare abbastanza benefici nell'esecuzione del refactoring, è possibile ottenere supporto gestionale.

Una volta che hai una tabella di marcia e il supporto di gestione, sviluppa una serie di passaggi (chiamati anche un piano) che devi prendere per raggiungere questo stato desiderato. Potrebbe essere una buona idea mettere insieme un comitato direttivo che mantenga la tabella di marcia, formi ed educi i team di sviluppo sulla tabella di marcia e riveda periodicamente le modifiche per l'integrità dell'architettura.

Le tabelle di marcia sono davvero utili e forse la tredicesima domanda sul test Joel dovrebbe essere "Hai una tabella di marcia?"

Ecco un video della prima ora di una recente sessione della roadmap di Red Hat Linux .

Essendo già stato coinvolto in un'importante riscrittura, (non solo refactor), posso essere d'accordo sul fatto che far accettare i ragazzi finanziari al progetto sia stato uno dei maggiori ostacoli. Superare quell'ostacolo mi ha richiesto di scrivere, presentare e difendere un rapporto che evidenziava una serie di problemi che indicavano che l'attività delle aziende sarebbe stata interrotta nell'acqua nel breve e medio termine.

Fattori chiave per ottenere l'accordo per andare avanti:

• Il codice esistente si trovava in una catena di strumenti non più supportata (MicroPower Pascal), che funzionava solo su una piattaforma di sviluppo quasi insopportabile (PDP11-23).
• Trovare sviluppatori in grado di lavorare su strumenti e obiettivi stava diventando quasi impossibile.
• L'hardware di destinazione non era più disponibile se fossero necessari pezzi di ricambio e il produttore stava diventando sempre più riluttante a fornire un servizio di riparazione.
• I problemi del codice causavano insoddisfazione del cliente facilmente identificabile e costi di manutenzione diretta.
• L'aggiunta di nuove funzionalità o persino la correzione di bug stava diventando quasi impossibile a causa delle limitazioni dell'hardware di destinazione, con la conseguente necessità di refactoring di altre aree in modo da fornire spazio quando si affrontano i problemi.
• Con un tempo di costruzione di 8 ore lo sviluppo e il test di eventuali modifiche sono stati costosi.

Il rapporto ha dettagliato i problemi, con stime dei costi in corso, e ha offerto 3 opzioni:

1. Congelati dove probabilmente non avremmo nemmeno risolto i bug nel prossimo futuro.
2. Ottimizza il codice solo per lo spazio, indipendentemente dalla manutenibilità, sottolineando che chiunque tenti di mantenere il codice ottimizzato dovrebbe essere più intelligente di chiunque abbia fatto l'ottimizzazione.
3. Reimplementare, con testabilità e manutenibilità come fattori elevati, in uno standard industriale, ampiamente insegnati, linguaggio (ANSI C), su hardware COTS nuovo, a basso costo, (PC-104), con più fornitori disponibili con un servizio interno scheda di interfaccia progettata per consentirne il funzionamento con l'hardware esistente rimanente. Aggiungendo una serie limitata di nuove funzionalità come parte dello sviluppo come l'archiviazione non volatile, un timer di controllo per fornire il riavvio automatico in una condizione di errore alcune unità si arrestavano in modo anomalo più volte al giorno e richiedevano un richiamo del servizio di £ 40 per ripristinare , migliore diagnostica nel processo.

Avendo ottenuto il via libera per la terza opzione, il mio contratto di 3 mesi si è trasformato in 3 anni di duro lavoro, sia nello sviluppo del nuovo software che dell'hardware, ma con un ottimo risultato.

Per i casi con un debito tecnico meno estremo tendo ad adottare quello che chiamo refactoring di guerriglia:

In caso di problemi con un modulo specifico:

1. Scrivi una serie di test che dimostrano il problema che potrebbe anche fallire senza refactoring
2. Refactor come parte dello sviluppo sottolineando che i test continuano a fallire.