Come posso convincere il management a gestire il debito tecnico?

Quando ho incontrato il mio capo per discuterne, ha detto che dovevo 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. Considera solo una parte inespressa di tutte le tue stime e scoprirai che il debito tecnico diminuisce.

Tuttavia non sarà mai perfetto. Il debito tecnico, come il debito della carta di credito, è un investimento per ottenere clienti più velocemente e guadagnare quote di mercato più velocemente rispetto alla concorrenza. Come il credito, se gestito correttamente, può farti avere abbastanza successo.

È come ha detto Gandhi quando gli è stato chiesto se la sua tattica avrebbe funzionato con qualcuno come Hitler. Ha detto, "Sarebbe difficile." Ma penso ci sia un giusto argomento che la risposta sia davvero "no". Purtroppo, non penso che si possa fare ciò che stai cercando di fare. Non sto cercando di essere pessimista, ma piuttosto sto cercando di essere onesto.

Il problema per me non è che i manager hanno bisogno di essere convincenti. I migliori capiscono già che il debito può essere un killer se non è gestito. Ma che lo capiscano o meno, che siano buoni o cattivi manager, tutti devono affrontare la pressione di consegnare, e quella consegna viene giudicata dai loro padroni contro una data. La qualità conta solo se è estremamente grave, nel qual caso è colpa degli sviluppatori, o estremamente buona, nel qual caso è la genialità del management che l'ha fatta accadere. La qualità deve solo essere "abbastanza buona".

Penso che mi piaccia 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 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 davvero coraggiose che hanno il coraggio di dire "Sarà fatto quando sarà finito" (come Apple Computer o id Software) e sì, capisco che a volte le persone non sono libere adottare tale approccio).

Ma ecco il punto: le aziende che adottano l'approccio di qualità ... cosa ne sai di loro? Esatto, sono gestiti da ingegneri, non da venditori, venditori, project manager o contabili. Pensa a HP, Apple, id, Google, Microsoft e IBM. Tutto è iniziato e realizzato con successo da ingegneri, non da venditori, anche se i venditori hanno sicuramente avuto un ruolo importante, e sono sicuro che molti avrebbero discusso di avere Microsoft associato alla qualità :). E di quelli, quelli che sono andati in discesa si sono allontanati dalla leadership guidata dall'ingegneria. C'è tutta una serie di argomenti in quella affermazione, però, poiché ci sono un sacco di aziende tecniche che alla fine hanno fallito a causa dell'incapacità di adattarsi ai tempi che cambiano e di gestire la propria crescita. Non vedo la leadership basata sull'ingegneria come la causa di quei fallimenti, per me è una questione di abilità e acume aziendale che sono indipendenti da qualcuno che è uno sviluppatore o un contabile. Penso in generale, tuttavia, che ci sia una dedizione nell'ingegneria ai rigori della responsabilità e della disciplina che avvantaggia le aziende in cui l'ingegneria è un componente.

Seriamente, guardati intorno. La leadership IT è gravemente carente. L'attenzione è sempre sul costo e sul tempo, e raramente sulla qualità finché è abbastanza buono. I responsabili IT raramente riferiscono al CEO, ora è sempre il direttore finanziario. L'IT è bloccata nel sostenere la produzione e sempre più nei confronti dei project manager che si concentrano su pezzi più piccoli, più digeribili e misurabili, non su 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 impiegare così tanto tempo su questo post, ma alla fine penso che la tua domanda, su come fare attenzione alla gestione del debito tecnico, sia spesso risolta meglio trovando il leader giusto, piuttosto che cambiando quello esistente. Spiegare il debito tecnico ai pensatori standard significa cambiare l'attenzione al denaro e ai costi, come ha detto Renesis, e penso che per la traduzione si perda molto; anche se ci riuscissi, sarebbe importante se l'azienda leader della compagnia lo comprasse. Convincere il tuo middle manager a fare la cosa giusta probabilmente lo farà licenziare.

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

Consentire di andare non retribuito ha un costo enorme che non può essere visto o facilmente quantificato.

Elenca i problemi come i seguenti per la gestione:

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

La mia gestione 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 è valso.

Un modo per mantenere la pressione è quando mi viene chiesto un preventivo, e il tempo avrebbe potuto essere risparmiato se non avessi dovuto affrontare problemi tecnici specifici del debito, includo questo nella mia stima . Ad esempio, " questo bug mi richiederà 2-3 giorni per rintracciare, ma se avessimo già indirizzato questi 2 altri bug" a bassa priorità "che sono rimasti in coda per sempre, probabilmente ne impiegherebbe meno di uno. "Spesso, la risposta sarà di andare avanti e aggiustare gli altri mentre ci sei.

Sono anche d'accordo con altre risposte sul considerare solo i miglioramenti come parte del tuo lavoro e sul come farlo se non è troppo dirompente. Il mio compito attuale consiste nel fare aggiunte a codice molto mal progettato. Piuttosto che aumentare il disordine scrivendo il mio nuovo codice per abbinarlo, sto passando un po 'di tempo prima a consolidare le funzionalità comuni, quindi l'invio di un pacchetto diventa una chiamata di una linea invece di ripetere costantemente 15 righe di copia leggermente modificata e pastaplastica.

So per certo che salverà ulteriormente la sanità mentale di un manutentore. Lo so perché sono quel maintainer oggi. Tuttavia, credo anche che accelererà il mio attuale compito di ottenere questa funzione e di eseguire il debug ora.

Un'altra tecnica che ho usato in passato e che dovrei fare di nuovo è mantenere un ramo di refactoring DVCS in un albero di lavoro separato per quel tempo di attesa durante la compilazione, in attesa di un lungo prova, o semplicemente hai bisogno di un cambio di ritmo per un po 'quando sei bruciato su un bug. Fintanto che occasionalmente ti unisci da monte per non divergere troppo, puoi impiegare tutto il tempo che desideri per rifattare le modifiche con uno sforzo marginale minimo. 15 minuti qua e là al giorno possono davvero aumentare nel tempo.

Potresti provare l'analogia con la carta di credito. Chiedigli "ti senti a tuo agio lasciando le schede della tua carta di credito non pagate per un lungo periodo di tempo?"

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

Ma se questo non li convince, prova a raccogliere prove concrete e fare alcuni calcoli. Per esempio. quanto costa all'azienda - sia in contanti che in perdita - 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 faccia di più, cioè unire il servizio del debito tecnologico a un upgrade che porti benefici aziendali immediati e tangibili.

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

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

Nessuna quantità di convincente cambierà la situazione, e se introduci uno standard di qualità del codice obbligatorio, i tuoi sviluppatori da nove a cinque troveranno un modo per utilizzare il sistema, mentre i tuoi sviluppatori dedicati saranno inevitabilmente infastiditi dall'intera procedura (che non è rivolto a loro, ma non puoi dire che lo sviluppatore X deve rispettare le regole, mentre Y può fare tutto ciò che vuole).

Ciò che funziona, ma può ancora essere molto frustrante è avere gli sviluppatori più dedicati e ben informati che supervisionano la base di codice, probabilmente un buon compromesso tra andare avanti e mettere in ordine ciò che è al di là di questo.

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

Oppure scendono, fast .

A meno che i clienti esistenti non siano disposti a pagare per il refactoring, il che è profondamente improbabile a meno che non venga fornito con prestazioni o funzionalità significativamente aggiornate. Quindi non succederà nelle codebase precedenti. Potresti essere in grado di introdurlo nel budget per i progetti più recenti, se i clienti hanno delle tasche profonde, ma a meno che tu non abbia bisogno di cambiare le API nel refactoring, non sarà di alcuna utilità per i progetti più vecchi e potrebbe introdurre un situazione in cui la società supporta due codebase, il che provoca ulteriori grattacapi e costi.

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

Cerco sempre di ripulire 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 è non accumularne nessuna. Se i tuoi manager si fidano dei tuoi sviluppatori per decidere come risolvere un problema, puoi rendere l'igiene del codice parte di ogni attività di programmazione. Se non controlli mai il codice errato non accumuli debiti. Se segui anche la regola Boy Scout (lascia sempre il codice più pulito di quello che hai trovato) la tua esistente il debito sparirà lentamente.

Non vedo il refactoring come un'attività separata dalle funzionalità di implementazione. Ne è parte integrante

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

Analizza quanto tempo gli sviluppatori sono costretti a spendere per supportare il supporto con problemi di produzione, quindi verifica che aggiustando il vecchio vecchio codice A. riduca il numero di problemi di supporto, B. sia più facile per il Supporto risolvere i problemi senza inoltrarsi a Sviluppo e C. Riduzione del tempo Lo sviluppo spende per problemi di produzione quando si presentano. Mettilo in termini di dollari risparmiati non avendo gli sviluppatori legati a fare lavori di supporto. Indica inoltre che ogni ora che uno sviluppatore spende per fare supporto è un "doppio smacco" perché non solo paghi uno sviluppatore per fare supporto, ma stai bruciando il costo opportunità di quello che potrebbe fare lo sviluppatore (aggiungendo nuove funzionalità, ecc. .)

Sì, alcuni dei numeri saranno voodoo / fumo-e-specchi ... va bene, lo sporco segreto della gestione è che loro sanno che la maggior parte dei numeri che lanciano sono BS totale Fintanto che dai loro qualcosa di apparentemente concreto con cui lavorare, in modo che riescano a capirlo, hai una possibilità di combattere.

Dopo questa spiegazione del debito tecnico, la tua gestione dovrebbe essere convinta di ripagarla:

Imagine that you have a very dirty kitchen full of crap. Before preparing a meal, you have to first spend one hour cleaning. And it is like that every time you want to eat. Also, when preparing a meal, you have to be extra careful, to make sure the crap does not fall in your meal.

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

Se possono permettersi di aspettare più a lungo per implementare una modifica, senza una rete sicura di test unitari, allora c'è qualcosa di sbagliato 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 gestione o i tuoi clienti pagano per questo e devi essere in grado di vendere a aka convincerli.

Facciamo una riformulazione per posizionarti come cliente. Buon vecchio gioco di ruolo.

Suppose you were buying a refrigerator. And you could buy a fridge for $1000 that worked OK from Acme Corp. Or a fridge for $2000 from Acme Deluxe Fridges that looked the same on the outside and had the same technical specs, but had lower maintenance costs due to a cleaner internal architecture.

Come cliente, che compreresti tu stesso?

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

" Il debito tecnico " può essere un soggetto difficile da presentare alla direzione in quanto potrebbero non vederne la necessità. La domanda potrebbe essere formulata come se ci sia o meno un campione in azienda a dichiarare: "Ecco, stiamo prendendo X% di tempo per lavorare sul debito tecnico qui. Dacci 3 mesi per mostrarti che funziona bene" o qualcosa del genere simile. C'è una rivendicazione verso l'autonomia, ma anche un periodo di tempo perché altrimenti la direzione potrebbe chiedersi quanto tempo ci vorrà per vedere alcuni risultati che sono un territorio piuttosto pericoloso.

Il primo punto è se lo vedono o meno come un problema. Se la persona con problemi di vista non sa nulla degli occhiali da vista e quali tipi di cambiamenti possono fornire, come possono capire perché un esame oculare può essere utile? Stessa idea qui dove il soggetto è piuttosto tecnico e non facilmente quantificabile purtroppo.

Dovresti semplicemente smetterla di lamentarti.

Ecco perché:

1. Non hanno mai in programma di utilizzare il software più di un anno
2. è solo una perdita di tempo modificarlo se il loro piano è di scaricarlo successivamente
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. lamentandosi di sapere che cosa è meglio fare è arrogante - qualcun altro prende la decisione, e dovresti esserne felice
6. Comunque ti fidi di scrivere un buon codice

Quindi il modo migliore è:

1. Quando ti danno un nuovo compito, prova ad implementarlo nel miglior modo possibile
2. scrivilo perfettamente la prima volta. Se hai bisogno di cambiarlo dopo, hai commesso un errore la prima volta e ogni cambiamento è sempre andato nella direzione sbagliata - ed è un'opportunità di apprendimento per i programmatori quando commetti degli errori.
3. Non chiedere più tempo, non lo prendi, ci sono scadenze che conosci.

Considero che non sei mai stato coinvolto in un progetto per riscrivere / sostituire o anche aggiornare e sistema esistente.

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

1. Le regole aziendali sono perse nel tempo.
2. La documentazione e l'implementazione sono totalmente fuori sincrono.
3. Quello che vedi come un bug che gli utenti vedono come una funzionalità.
4. Viceversa molte "caratteristiche" saranno considerate come difetti dagli utenti.
5. Non riceverai l'acquisto da parte degli utenti - considereranno la tua "ricerca di fatti" come "nerd che fanno domande stupide", considereranno lo sforzo di test come una perdita di tempo, insisteranno sull'aggiunta di nuove funzionalità allungando così un il progetto sarà già in ritardo.
6. È probabile che il codice sorgente non corrisponda al 100% con l'eseguibile in esecuzione.
7. Mentre il tuo dipartimento si occupa di refactoring, l'attività in realtà non viene eseguita.
8. È probabile che il tuo ri-factoring implichi "interfacce migliorate più pulite", trascinando così altri progetti nel tuo pantano di consegna tardiva e test falliti.
9. Dopo che il progetto è stato inscatolato (ben oltre il 50% di questi sforzi falliscono completamente) avrai perso ogni credibilità - dovrai trasferirti in un'altra città in un'altra città per trovare qualcuno disposto ad ascoltarti anche tu.
10. Se il progetto "succede", tutti ricorderanno che incubo è stato - lo farai .......

Ti esorto a evitare qualsiasi ri-scrittura / refactoring di progetti come la peste, possono essere alcune delle esperienze più scoraggianti in ogni carriera professionale.

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

Per la vita di me non riesco a capire perché alcune persone siano così ciecamente spaventate dal cambiamento - sa di mancanza di fiducia nelle proprie capacità.

Ho visto uno spettacolo la scorsa notte su Yosemite National Park e ho notato che dal 1940 alla fine degli anni '90 non è spuntato un solo nuovo albero Sequoia. Si scoprì che il motivo per cui esisteva una rigorosa politica contro la necessità di bruciare gli incendi boschivi e che le pigne di sequoia avevano bisogno del calore del fuoco per aprirsi e liberare i loro semi.

Vedi, un incendio ogni dieci anni circa era sano. Ha eliminato tutto il deadwood e il rovo accumulati per mantenere sani gli alberi esistenti (processi) e creare spazio per quelli nuovi (caratteristiche).

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

La gestione è dietro l'attività perché hanno una giusta dose di 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 cambiamenti audaci è l'unico modo per esistere come sviluppatore di software.

Buona fortuna!

Devi dare alla tua direzione un motivo finanziario per affrontare il debito tecnico e un quadro per la gestione della riduzione di tale debito tecnico.

Il mantenimento di una roadmap tecnologica è uno di questi framework. Iniziare con una roadmap ti aiuterà a evitare 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. Sono particolarmente utili quando sono coinvolti più team di sviluppo e parti interessate.

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

L'approccio generale alla creazione e alla gestione di una roadmap è semplice, ma richiede il supporto del tuo team di gestione. Innanzitutto, definisci un obiettivo. Definisci gli elementi del debito tecnico e sviluppa un'architettura di sistema di destinazione che riduca gli elementi del tuo debito tecnico. Ricorda, non deve essere perfetto, solo praticabile 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 riescono a mostrare sufficienti vantaggi nell'effettuare il refactoring, è possibile ottenere supporto gestionale.

Una volta che hai una roadmap e un supporto gestionale, sviluppa una serie di passaggi (chiamati anche piani) che devi seguire per arrivare a questo stato desiderato. Potrebbe essere una buona idea mettere insieme un comitato direttivo che mantenga la tabella di marcia, formi e istruisca i team di sviluppo sulla tabella di marcia, e riveda periodicamente le modifiche per l'integrità architettonica.

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

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

Essendo già stato coinvolto in una grande riscrittura, (non solo un refactoring), posso essere d'accordo sul fatto che il fatto che i ragazzi finanziari siano d'accordo con il progetto è stato uno dei principali ostacoli. Superare quell'ostacolo mi ha costretto a scrivere, presentare e difendere un rapporto che evidenziava una serie di problemi che facevano sì che il business delle aziende sarebbe morto nell'acqua nel medio-medio termine.

Fattori chiave per portare avanti l'accordo:

• Il codice esistente era in una catena di strumenti non più supportata, (MicroPower Pascal), che funzionava solo su una piattaforma di sviluppo quasi insopportabile, (PDP11-23).
• Trovare sviluppatori che potessero lavorare su strumenti e obiettivi stava diventando quasi impossibile.
• L'hardware di destinazione non era più disponibile se i ricambi erano necessari e il produttore e il produttore stavano diventando sempre più riluttanti a fornire un servizio di riparazione.
• I problemi nel codice si traducono in insoddisfazione dei clienti prontamente identificabili e costi di assistenza diretti.
• L'aggiunta di nuove funzionalità o persino di correzioni di bug diventava quasi impossibile a causa delle limitazioni dell'hardware di destinazione, con la conseguente necessità di ridefinire 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 delle eventuali modifiche è stato costoso.

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

1. Blocca dove eravamo con eventuali correzioni di bug, anche nel prossimo futuro.
2. Ottimizza il codice solo per lo spazio, senza tenere conto della manutenibilità, sottolineando che chiunque tenti di mantenere il codice ottimizzato dovrebbe essere più intelligente di chiunque abbia fatto l'ottimizzazione.
3. Re-implementare, con testabilità e manutenibilità come fattori elevati, in uno standard di settore, linguaggio ampiamente insegnato, (ANSI C), su hardware COTS nuovo, a basso costo, (PC-104), con più fornitori disponibili con una scheda di interfaccia progettata internamente per consentirne il funzionamento con l'hardware esistente rimanente. Aggiunta di una serie limitata di nuove funzionalità come parte dello sviluppo, come la memoria non volatile, un timer watchdog per fornire il riavvio automatico in una condizione di errore alcune unità si sono bloccate più volte al giorno e richiedono un intervento di £ 40 per ripristinare , diagnostica migliore nel processo.

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

Per i casi con un debito tecnico meno estremo tendo ad adottare ciò che chiamo refactoring della guerriglia:

Quando c'è un problema 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 stanno ancora fallendo.