Incolpare i mali di oggi sul debito tecnico di ieri

Un numero sorprendente di problemi di qualità, scalabilità e carico si sono verificati su un'applicazione che attualmente supporto e che inizialmente non avevo scritto. Per fortuna ho nuovi progetti che ho fatto da zero per mantenere una parvenza della mia sanità mentale.

Il team originale era composto da 20 sviluppatori (la maggior parte con insiemi di competenze obsoleti), senza documenti relativi ai requisiti aziendali o ai tester di controllo della qualità, e gestiti male fin dall'inizio in maniera a cascata. I primi giorni della produzione furono un incubo imbarazzante che prevedeva la correzione di un fragile codice procedurale con correzioni ancora più fragili. Successivamente sono state aggiunte funzionalità che sono state integrate in un modello di dati che non è mai stato pensato per supportarle e non è raro vedere lo stesso codice duplicato 10 volte e vedere risorse non essere chiuse in modo sicuro e query ORM che raccolgono decine di migliaia di entità solo buttare via tutto tranne una manciata.

Sono solo io ora e ogni volta che si presenta un nuovo problema, riscrivo un modulo secondo standard migliori e lo rendo MOLTO più stabile, ma la direzione ha bisogno di una spiegazione adeguata sul perché tutto ciò si sta verificando.

Sembrano scioccati e perplessi all'idea che questa applicazione sia di scarsa qualità e che affoghi nel debito tecnico. Fortunatamente comprendono il concetto di debito tecnico e mi supportano nella mia ricerca per sradicarlo e mi supportano e mi apprezzano molto, ma mi sento come se continuassi a incolpare il team originale (che è partito per rovinare un altro progetto in un altro divisione).

La linea di fondo è che non voglio essere "Quel ragazzo" che si lamenta sempre degli sviluppatori del progetto prima di lui. In precedenza ho visto questo atteggiamento da parte di persone della mia carriera che personalmente sentivo ignoranti e non consideravano le circostanze e le influenze progettuali che incoraggiavano le cose a essere come erano.

Di solito vedo questo atteggiamento di incolpare il team precedente per la cattiva progettazione e implementazione da parte di sviluppatori junior idealisti che non hanno avuto le esperienze di vita che più membri senior hanno avuto e di cui hanno beneficiato.

Ritieni che esista un modo migliore, forse più semplice, di segnalare questo tipo di problemi alla direzione senza fare un passo sulla reputazione della persona / squadra davanti a te?

Il debito tecnico è come il debito finanziario. Lo affronti (si spera) strategicamente nello sviluppo di un programma con l'intenzione che sarà ripagato in futuro. A volte le persone prendono scarse decisioni di debito tecnico (come ad esempio una carta di credito), ma a volte una certa quantità di debito tecnico è semplicemente normale. Decidere di non dedicare il tempo a fare qualcosa nel modo "giusto" oggi supponendo che dovrà essere cambiato in futuro è del tutto normale e dovrebbe essere anticipato. Naturalmente c'è una linea sottile, ma pensare che la prima volta riuscirai a farlo nel modo giusto può causare il suo insieme di problemi (analisi paralisi).

In conclusione, qualsiasi progetto non banale che dura da più di un paio d'anni dovrà dedicare un po 'di tempo di sviluppo a ripagare il debito tecnico. Il fatto è che questo è vero anche se scrivi l'applicazione nel modo giusto . Se non lo fai, stai accumulando debito su debito, e la direzione può certamente capirlo se lo presenti in quel modo.

Spiega questo alla direzione e invece di "incolpare" il team precedente per tutto il tempo, puoi presentarlo come "affari come al solito".

IMO, lo stai già affrontando per lo più nel modo giusto: non stai suggerendo una riscrittura da zero perché "il vecchio codice fa schifo", ma aggiusta una cosa alla volta.

Per evitare di sentirti come se stessi incolpando la vecchia squadra, immagina che probabilmente hanno dovuto produrre questo codice sotto grande pressione del tempo. Il management in quel momento probabilmente non lo capì proprio perché il codice "più o meno funziona" non significa che qualsiasi manutenzione sia possibile senza molto dolore e rilavorazioni.

Apprezzo il vecchio team per essere riuscito a realizzare un prodotto che offra effettivamente un valore aziendale - non sarebbe più in uso se non lo facesse. Potresti essere sorpreso dalla frequenza con cui un progetto non riesce a fornire valore aziendale, anche se è scritto magnificamente.

Quando mi viene chiesto di commentare lo stato attuale di un prodotto problematico, torno sempre indietro, "è quello che è" e quindi inizio a parlare di piani per migliorarlo.

Non conosci tutti i fattori che sono stati presi nella decisione che ha creato questo problema - forse erano persino ragionevoli al momento. Tutto quello che puoi fare è andare avanti e migliorare le cose domani. E sembra che tu stia facendo un buon lavoro: hai l'atteggiamento giusto per questa situazione.

Concentrati solo sulla segnalazione dei fatti quando ti viene chiesto. Non è necessario aggiungere narrativa o commento; dì semplicemente "il sistema non funziona nel caso X" o "i rapporti non sono corretti per il caso Y." Quindi aggiungi rapidamente come intendi migliorare la situazione attuale.