Come posso essere pagato per ridurre il debito tecnico?

Passaggio 1: Interrompi il lavoro straordinario non retribuito.

Hai già addestrato il tuo cliente e manager per un anno a credere che l'attuale tasso di sviluppo sia quello che dovrebbe essere previsto. Questo è parte del motivo per cui non capiscono perché una cosa "semplice" potrebbe richiedere un giorno intero da fare. Non è necessario tenerli in ostaggio e tentare di danneggiare il progetto. Ma devi spiegare che le loro aspettative sono troppo alte e hai bisogno di un altro sviluppatore o più tempo prima della scadenza. Spiega in modo specifico al tuo manager che hai lavorato straordinari non retribuiti e stai pianificando di non farlo altrettanto. Anche se lo riduci a 9 ore al giorno, la differenza verrà notata. Se il tuo manager ti chiede perché non stai facendo il tuo lavoro, puoi indicare il fatto che hai fatto un punto per avvertirlo che questo sarebbe il caso.

Passaggio 2: prendere appunti

Solo perché non hai tempo per fare il lavoro, non significa che non puoi renderlo più facile quando il lavoro (si spera) viene fatto. Tieni traccia delle idee che hai per correggere il codice e portalo alle riunioni in modo che gli altri siano consapevoli delle tue preoccupazioni. Alla fine colpirai una patch lenta o le persone inizieranno a capire che le tue preoccupazioni hanno un valore. Quando arriverà questo momento, avrai già alcune idee di base su cosa fare invece di venire a secco perché non hai guardato una sezione di codice per un po '.

... the code is really hard to maintain.

Questo è il tuo modo di gestire. Dimostra che il costo di "solo" correggere i bug e aggiungere nuove funzionalità è maggiore di quello di refactoring e riscrittura del codice.

Ad esempio se con il codice corrente una nuova funzione impiegherebbe 2 settimane per aggiungere e quindi una quantità significativa di tempo da mantenere (es. 1 giorno a settimana), mostra che con un refactoring di una settimana puoi ottenere lo sviluppo in 1 1/2 settimane ma che riducerai la manutenzione a 1 giorno al mese (o meno). Questi numeri mostreranno che ciò che stai facendo è conveniente a medio-lungo termine anche se c'è un costo a breve termine.

Mentre la società potrebbe non gradire spendere i soldi ora, vedranno che i potenziali benefici sono molto più grandi - cioè sarai più produttivo generando più codice in meno tempo e quel codice sarà di migliore qualità.

Applica la regola Boy Scout : lascia il codice un po 'più ordinato (cioè con un debito meno tecnico) ogni volta che lo tocchi.

Concediti del tempo per farlo in tutte le stime che dai. Quindi, magicamente, col tempo il debito tecnico sparirà e sarai pagato per farlo.

Questo approccio è molto più facile che cercare esplicitamente di ritagliare il tempo (e quindi convincere i clienti / gestori a pagare) per il debito tecnico. Ti dà una maggiore sensazione di professionalità e un "lavoro ben fatto". Infine, i tuoi clienti e dirigenti ti ringrazieranno a lungo termine, anche se non capiscono come sia successo .....

Questa è più o meno la triste realtà della programmazione di manutenzione. Sei bloccato con quello che ti viene assegnato per mantenere e se la persona che paga le bollette non vuole pagare per quello che considera essere senza cambiamenti, allora quelle modifiche tendono a non essere fatte.

Se vuoi dimostrare di aver finanziato queste modifiche, tieni un registro di tutti i luoghi che devi modificare anche per l'aggiornamento più semplice. Dopo alcune modifiche, discuti quel registro con il tuo manager. Se riesci a documentarlo, c'è una possibilità (anche se molto sottile) che la persona con i cordoni della borsa si renderà conto che è effettivamente più economico a lungo termine pulire il codice ora in quanto renderà le modifiche future più economiche.

Le tue possibilità di vendere questo aumentano più a lungo si prevede che questo prodotto sarà in uso. Le probabilità aumentano anche se un errore nel prodotto può causare problemi di pubbliche relazioni per il cliente o costi per il cliente.

Escluso questo, apprendi ciò che puoi e passa ad un'altra posizione con meno manutenzione.

Devi dimostrare alla tua direzione in che modo il refactoring e il miglioramento in altro modo del prodotto andranno a beneficio dell'azienda.

È improbabile che il cliente si interessi se il codice è bello o brutto finché funziona, e la direzione non sarà desiderosa di spiegare al cliente che ciò che ha già pagato è stato progettato male e implementato male. Allo stesso tempo, la direzione non sarà desiderosa di mangiare il costo del tempo di sviluppo che non migliora il prodotto in qualche modo visibile (fatturabile).

Quindi ... devi convincere il management che le modifiche che proponi aiuteranno l'azienda:

• Mostra loro che un'architettura migliore ti consentirà di aggiungere nuove funzionalità più rapidamente.
• Spiega che proseguendo lungo il percorso attuale si dipingono in un angolo.
• Fornisci esempi di modifiche che sono molto costose da realizzare nel sistema attuale, ma che sarebbero semplici ed economiche con un design migliore.
• Tieni traccia del tempo trascorso a mantenere il codice legacy rispetto all'aggiunta di funzionalità vendibili. - Aiutali a spiegare ai clienti esistenti e futuri che, mentre il sistema esistente era abbastanza buono, la nuova architettura modernizzata consentirà molti nuovi, grandi miglioramenti, una migliore affidabilità e così via.
• Mitiga il rischio associato alle modifiche che proponi. I manager sono avversi al rischio e le modifiche radicali a un sistema esistente sembrano intrinsecamente rischiose.
  • Dai la priorità alla modernizzazione dei vari componenti in base ai costi e ai vantaggi e assicurati che la gestione sia d'accordo con le tue priorità.
  • Utilizza i test delle unità per garantire che i componenti aggiornati siano compatibili con il codice legacy rimanente.
• Tieni traccia dei progressi dello sforzo di modernizzazione. Mostra i vantaggi non appena puoi, ma ricorda a tutte le parti che c'è molto lavoro da fare.

Potresti non rendertene conto, ma Johnny Cash ha predetto il movimento di refactoring e ha scritto una canzone sul modo migliore per ridefinire una grande base di codice esistente.

Ovviamente, ha dovuto avvolgerlo in una metafora automobilistica in modo che il suo pubblico potesse identificarlo.

"Un pezzo alla volta" - Johnny Cash

Sembra che potresti addebitare al cliente il tempo in cui la modifica "dovrebbe" prendere e continuare a essere WAY ahead a lungo termine.

Se ti piace pulire il codice (e sembra che lo fai almeno un po '), vai avanti e continua a farlo ma non bruciarti. Questo non fa bene a te, alla tua azienda o ai tuoi altri clienti.

Assicurati che la tua gestione e chiunque lavori con il cliente sappia che il codice non è nella forma migliore in modo che possano prendere una decisione informata: solo perché il tuo codice è di proprietà non significa che devi prendere le decisioni aziendali a questo proposito, se non sono a conoscenza dei problemi con il codice, allora non possono fare il loro lavoro.

Sebbene l'applicazione del cliente abbia qualche debito tecnico, non dimenticarlo, probabilmente sono stati accusati di un leggero sconto. Potrebbero non esserne stati informati, ma è quello che succede quando prendi l'offerta più bassa.

Devono decidere se vogliono pagare l'intero prezzo per le modifiche alle funzionalità o fare a meno di loro. È una loro scelta. Puoi lasciare che prendano la decisione o continuare a lavorare gratuitamente. Puoi provare a menzionare il lavoro di pulizia che hai fatto e offrire un leggero sconto per il lavoro completato. Di nuovo, è la loro scelta.

Il modo in cui mi avvicinerei a questo è iniziare a spiegare il concetto di debito tecnico ai tuoi capi per assicurarti che lo ottengano. Approccio da una linea di fondo, prospettiva di business. Ogni volta che richiedono una nuova funzionalità, il debito tecnico accumulato nel prodotto influisce sulla tua efficienza e, pertanto, ogni funzione costa un po 'di più a causa di questo debito.

Una volta che capiscono di cosa stai parlando, prova a negoziare per un po 'del tuo tempo per ridurre il debito tecnico. Nella mia azienda abbiamo avuto ragionevolmente successo con petizioni per il 10% dei tempi di ogni sviluppatore al fine di lavorare sulla riduzione del debito tecnico.

Una volta che hai un po 'di tempo da dedicare a questo, assicurati di usarlo effettivamente (e non limitarti a fare il 10% di lavoro straordinario per farlo - atteniti alle tue pistole). Creare un catalogo di elementi di debito tecnico e dare la priorità a loro e iniziare a ritagliarsi. Devi mangiare l'elefante un boccone alla volta.

E non dimenticare di prendere in considerazione strumenti migliori. Resharper è un ottimo strumento di refactoring che si collega a Visual Studio.