Come posso essere pagato per ridurre il debito tecnico?

Attualmente sto lavorando per una piccola azienda che ha pochi prodotti tecnicamente complicati. Sono l'unico e unico sviluppatore per uno di loro. Circa un anno fa, ho ottenuto la versione legacy del prodotto e ho iniziato a "supportarlo".

Il cliente parla solo di nuove funzionalità, valore commerciale e altri di quel tipo. Il problema è che, sebbene il codice sia in C #, è abbastanza procedurale. Non ci sono astrazioni, le classi vengono utilizzate solo dove Visual Studio le richiede, ad esempio i moduli. Le implementazioni di queste classi sono davvero terribili e il codice è davvero difficile da mantenere.

Per tutti questi anni passo il mio tempo per il refactoring. Nell'ultima versione, ci sono piuttosto astrazioni e simili. Ho dovuto reimplementare un certo numero di componenti da zero e sento davvero che l'aggiunta di nuove funzionalità o il cambiamento del comportamento di questi componenti è MOLTO più facile che ad altri.

Il problema è che passo il mio tempo. Mi piacciono molto i risultati, ma non mi piace lavorare 12 ore al giorno. Sei mai stato in una situazione simile? Cosa dovrei provare? Ho già provato a discuterne, ma non ho ancora avuto successo.

Ho solo paura del momento in cui decidiamo di implementare la nuova funzionalità che richiede molte modifiche al codice legacy. Questo potrebbe essere scioccante per il cliente: perché hai bisogno di 8 ore per cambiare queste icone? Al cliente non importa che ci siano 500 posizioni nel codice che devo modificare. E dovrei anche trovare prima tutti questi 500 posti.

Qualche idea?

Passaggio 1: interrompere il lavoro straordinario non retribuito.

Hai già formato un cliente e un manager per un anno per credere che l'attuale tasso di sviluppo sia quello che ci si dovrebbe aspettare. Questo è uno dei motivi per cui non capiscono perché una cosa "semplice" potrebbe richiedere un'intera giornata. 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 di più tempo prima della scadenza. Indica in particolare di dire al tuo manager che hai lavorato straordinariamente 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 che hai fatto un punto per avvertirlo che 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 completato. Tieni traccia delle idee che hai per correggere il codice e presentale durante le 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 valore. Quando arriverà questo momento, avrai già alcune idee di base su cosa fare invece di prenderlo a secco perché non hai guardato una sezione di codice da un po '.

... il codice è davvero difficile da mantenere.

Questo è il tuo modo di entrare nella gestione. Dimostrare che il costo del "solo" correzione dei bug e l'aggiunta di nuove funzionalità è maggiore di quello del refactoring e della riscrittura del codice.

Ad esempio, se con il codice corrente una nuova funzionalità richiederebbe 2 settimane per essere aggiunta e quindi una quantità significativa di tempo per la manutenzione (ad es. 1 giorno alla settimana), mostrare che con il refactoring di una settimana è possibile completare lo sviluppo in 1 1/2 settimane, ma riducerai la manutenzione a 1 giorno al mese (o meno). Questi numeri mostreranno che ciò che stai facendo è conveniente nel medio-lungo termine, anche se c'è un costo a breve termine.

Mentre all'azienda potrebbe non piacere spendere i soldi ora, vedranno che i potenziali benefici sono molto maggiori - cioè sarai più produttivo generando più codice in meno tempo e quel codice sarà di qualità migliore.

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

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

Questo approccio è molto più semplice del tentativo esplicito di ritagliare il tempo (e quindi convincere clienti / gestori a pagare) per il debito tecnico. Ti dà una sensazione molto più grande di professionalità e un "lavoro ben fatto". E infine, i tuoi clienti e manager ti ringrazieranno a lungo termine, anche se non capiscono bene come sia successo .....

Questa è più o meno la triste realtà della programmazione della manutenzione. Sei bloccato con ciò che ti viene assegnato da mantenere e se la persona che paga le bollette non vuole pagare per ciò che considera cambiamenti senza beneficio, allora quei cambiamenti tendono a non essere eseguiti.

Se si desidera sostenere la necessità di finanziare queste modifiche, tenere un registro di tutti i luoghi che è necessario modificare anche per l'aggiornamento più semplice. Dopo alcune modifiche, discutere quel registro con il proprio responsabile. Se riesci a documentarlo, c'è una possibilità (anche se molto sottile) che la persona con le stringhe della borsa realizzerà che a lungo termine in realtà è più economico pulire il codice poiché renderà i cambiamenti futuri più economici.

Le tue possibilità di vendita aumentano tanto più si prevede che questo prodotto sarà in uso. Le probabilità aumentano anche se è probabile che un guasto nel prodotto causi un problema di pubbliche relazioni per il cliente o costi per il cliente.

A parte questo, impara cosa puoi e passa a un'altra posizione con meno manutenzione.

Devi mostrare al tuo management come il refactoring e il miglioramento del prodotto andranno a beneficio dell'azienda.

È improbabile che il cliente si preoccupi se il codice è bello o brutto fintanto che funziona e la direzione non sarà ansiosa di spiegare al cliente che ciò per cui ha già pagato è stato mal progettato e implementato male. Allo stesso tempo, il management non sarà desideroso di sostenere i costi dei tempi di sviluppo che non migliorano il prodotto in modo visibile (fatturabile).

Quindi ... devi convincere il management che i cambiamenti proposti aiuteranno l'azienda:

• Mostra loro che un'architettura migliore ti permetterà di aggiungere nuove funzionalità più rapidamente.
• Spiega che continuando lungo il percorso attuale si dipingeranno in un angolo.
• Fornisci esempi di modifiche che sono molto costose da apportare 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 attuali e futuri che mentre il sistema esistente era abbastanza buono, la nuova architettura modernizzata consentirà molti nuovi miglioramenti, maggiore affidabilità e così via.
• Riduci il rischio associato alle modifiche proposte. 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 a costi e benefici e assicurati che il management sia d'accordo con le tue priorità.
  • Utilizzare i test unitari per garantire che i componenti modernizzati siano compatibili con il codice legacy rimanente.
• Traccia i progressi dello sforzo di modernizzazione. Mostra i vantaggi non appena puoi, ma ricorda a tutte le parti che c'è ancora 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 refactoring di una base di codice esistente di grandi dimensioni.

Naturalmente, ha dovuto avvolgerlo in una metafora automobilistica in modo che il suo pubblico potesse identificarsi.

"Un pezzo alla volta" - Johnny Cash

Sembra che potresti addebitare al cliente per il tempo che il cambiamento "dovrebbe" prendere e comunque uscire in MODO a lungo termine.

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

Assicurati che la tua direzione e chiunque lavori con il cliente sappia che il codice non è nella forma migliore in modo che possano prendere una decisione informata - solo perché possiedi quel codice non significa che dovresti prendere le decisioni aziendali al riguardo, 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 dimenticare, probabilmente sono stati addebitati con un leggero sconto. Potrebbero non esserne stati informati, ma è quello che succede quando fai l'offerta più bassa.

Devono decidere se vogliono pagare il prezzo intero per le modifiche alle funzionalità o farne a meno. È la loro scelta. Puoi lasciarli prendere la decisione o continuare a lavorare gratuitamente. Puoi provare a menzionare il lavoro di pulizia che hai svolto e offrire un leggero sconto per il lavoro completato. Ancora una volta, è la loro scelta.

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

Quando capiranno di cosa stai parlando, prova a negoziare un po 'del tuo tempo per ridurre il debito tecnico. Nella mia azienda abbiamo avuto ragionevolmente successo con una petizione per il 10% di ogni tempo degli sviluppatori al fine di lavorare sulla riduzione del debito tecnico.

Dopo aver dedicato un po 'di tempo a lavorare su questo, assicurati di usarlo effettivamente (e non fare solo il 10% di lavoro straordinario per farlo - resta fedele alle tue pistole). Crea un catalogo di voci tecniche di debito e assegnale le priorità e inizia a intagliare. Devi mangiare l'elefante un boccone alla volta.

E non dimenticare di considerare gli strumenti migliori. Resharper è un ottimo strumento di refactoring che si collega a Visual Studio.