Incolpare i mali di oggi sul debito tecnico di ieri

38

Un numero sorprendente di problemi di qualità, scalabilità e caricamento si sono verificati su un'applicazione che attualmente suppongo di non aver scritto in origine. Per fortuna ho dei nuovi progetti che ho fatto fin dall'inizio per mantenere una parvenza della mia sanità mentale.

Il team originale comprendeva 20 sviluppatori (molti dei quali con set di abilità obsoleti), nessun documento sui requisiti aziendali o tester di garanzia della qualità, e mal gestito fin dall'inizio in modo cascata. I primi giorni di produzione erano un incubo imbarazzante che comportava l'applicazione di codice fragile procedurale simile a correzioni ancora più fragili. Le caratteristiche sono state aggiunte in seguito che sono state smascherate in una datamodel che non è stata pensata per supportarle e non è raro vedere lo stesso codice duplicato 10 volte e vedere le risorse non chiuse in modo sicuro e le query ORM che prelevano decine di migliaia di entità buttare via tutto tranne una manciata.

Sono solo io ora e ogni volta che c'è un nuovo problema che emerge Devo riscrivere un modulo per standard migliori e renderlo MOLTO più stabile, ma la Gestione 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 affoghi nel debito tecnico. Fortunatamente capiscono il concetto di debito tecnico e mi supportano nella mia ricerca per sradicarlo e sono molto solidali e riconoscenti nei miei confronti, ma mi sento come se continuassi a incolpare la squadra originale (che tutti lasciarono rovinare un altro progetto in una divisione diversa).

La linea di fondo è che non voglio essere "quel ragazzo" che si lamenta sempre degli sviluppatori del progetto prima di lui. Ho visto questa attitudine da persone della mia carriera che personalmente sentivo essere ignoranti e non considerando le circostanze e le influenze del design che incoraggiavano le cose a essere come loro.

Di solito vedo questo atteggiamento di incolpare il team precedente per la progettazione e l'implementazione inadeguate di sviluppatori junior idealizzati che non hanno avuto esperienze di vita di cui i membri più anziani hanno avuto e hanno beneficiato.

Ritiene che esista un modo migliore, forse più semplice, di segnalare questo tipo di problemi alla gestione senza cedere alla reputazione della persona / squadra prima di te?

    
posta maple_shaft 27.07.2011 - 15:40
fonte

3 risposte

46

Il debito tecnico è come il debito finanziario. Lo prendi (si spera) strategicamente nello sviluppo di un programma con l'intenzione che sarà ripagato in futuro. A volte le persone prendono delle decisioni scarse sul debito tecnico (come ad esempio una carta di credito), ma a volte una certa quantità di debito tecnico è normale. Decidere di non dedicare il tempo per fare qualcosa nel modo "giusto" oggi con l'assunto che dovrà essere cambiato in futuro è del tutto normale e dovrebbe essere anticipato. Ovviamente c'è una linea sottile, ma pensando che la prima cosa che farai sarà la causa della sua serie di problemi (paralisi dell'analisi).

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

Spiega questo al management e invece di "incolpare" il team precedente per tutto il tempo che puoi presentare come "business as usual".

    
risposta data 27.07.2011 - 16:21
fonte
23

IMO lo stai già facendo per lo più nel modo giusto: non stai suggerendo una riscrittura di base perché "il vecchio codice fa schifo", ma risolvendo una cosa alla volta.

Per evitare di sentirti incolpare la vecchia squadra, immagina che probabilmente dovessero produrre questo codice con una grande pressione. La gestione in quel momento probabilmente non lo capiva proprio perché il codice "più o meno funziona" non significa che qualsiasi manutenzione sia possibile senza un sacco di dolore e rilavorazione.

Apprezzare il vecchio team per la gestione di un prodotto che fornisce effettivamente un valore aziendale - non sarebbe più in uso se non lo fosse. Potresti essere sorpreso dalla frequenza con cui un progetto non riesce a fornire valore per il business, anche se è stato scritto in modo magnifico.

    
risposta data 27.07.2011 - 15:56
fonte
7

Quando mi viene chiesto di commentare lo stato attuale di un prodotto problematico, ricado sempre, "è quello che è", e poi inizi a parlare dei piani per migliorarlo.

Non conosci tutti i fattori che hanno determinato la decisione che ha creato questo problema, forse erano addirittura 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 di fatti quando ti viene chiesto. Non devi aggiungere la narrativa o il commento; basta dire "il sistema fallisce nel caso X" o "i report non sono corretti per il caso Y." Quindi aggiungi rapidamente come intendi migliorare la situazione attuale.

    
risposta data 27.07.2011 - 17:26
fonte

Leggi altre domande sui tag