HAVE A GEEK DAY

Il Blog di ELEVA

Quante volte ci siamo trovati con il fiato sul collo per il rispetto di una scadenza impossibile o per raggiungere obiettivi irrealizzabili. E’ capitato a tutti, in qualsiasi posizione lavorativa. Ecco, nei team di sviluppatori ed IT, capita un po’ più spesso e la ragione è principalmente una. C’è un gap di competenza importante tra chi prende decisioni basate su fattori economici e scadenze (CEO, COO o, a volte anche PM) e chi deve realizzare il lavoro nella sua complessità (CTO e team DEV, DevOps e IT).  

Chi opera su codice e infrastrutture sa bene che un progetto mal sviluppato tornerà presto a chiedere il conto. E stavolta lo farà con gli interessi. E’ qui che val la pena spiegare il concetto di debito tecnico. 

Cos’è il debito tecnico 

Il concetto è stato introdotto da Ward Cunningham, noto programmatore americano che fu anche coautore del Manifesto for Agile Software Development. In pratica, si accumula un debito tecnico quando prendiamo una scorciatoia nello sviluppo di un software, il più delle volte per rispettare una scadenza. Il codice scritto male però presto mostrerà i suoi limiti, rendendo più difficili eventuali modifiche ed estensioni future. Il tempo e lo sforzo extra richiesti per fare modifiche o aggiungere elementi al sistema costituiscono il debito tecnico.  

In pratica, se oggi risparmio mezza giornata per consegnare un progetto sviluppato male, mi ci vorrà molto più di mezza giornata per riscrivere il codice che mi consenta eventuali modifiche in futuro. E questo succederà sicuramente. Qualsiasi prodotto digitale richiede aggiornamenti, integrazioni e miglioramenti continui per rispondere alle richieste degli utenti finali. 

Semplificando estremamente, con l’introduzione di questa metafora, si cerca di allineare sugli stessi obiettivi le esigenze dei CEO (economiche) e quelle dei CTO (codice di qualità e funzionante, strutturato per consentire continue integrazioni), portando virtualmente tutto sul piano economico. Ma c’è un contraltare anche sul piano umano e professionale quando si accumula un debito tecnico. 

L’impatto del debito tecnico sulle persone 

Se gli sviluppatori nel tuo team iniziano a cambiare azienda o sono meno produttivi, potresti avere un problema di debito tecnico. Accumulare codice di scarsa qualità può dare il via a un circolo vizioso con conseguenze irrimediabili. E può essere molto difficile giustificare il perché di tempi inspiegabilmente lunghi nell’aggiungere minime modifiche a chi non è del settore. 

“In cinque minuti lo fai” 

Non è così quando la base di codice ha dei problemi a monte. Trovarsi di fronte a piccole integrazioni e dover riscrivere il codice da capo è molto frustrante per gli sviluppatori (oltre che lungo e complesso). A livello di team si genera una percezione di scarsa produttività, che viene spesso segnalata. Difficile spiegare il perché al tuo CEO… Il tutto genera ulteriore frustrazione e insoddisfazione. E un lavoratore infelice diventerà davvero, a questo punto, meno produttivo.  

“Ma chi ha scritto questo codice??” 

A nessuno piace lavorare su un codice con problemi di qualità e solidità. In molti casi poi si tratta di codice scritto da altri o software legacy obsoleto, di cui ci si deve assumere le conseguenze. Senza che i meriti del “restauro” – ossia del refactoring – vengano riconosciuti. Anzi, spesso si generano attriti all’interno dei team e malcontento che viene ereditato, insieme al progetto, da nuovi membri che entrano in azienda.  

“Ci hanno tagliato il budget” 

Sviluppare buon codice è un investimento per il futuro. Un concetto che però non è facile far capire a chi prende decisioni in azienda, in tempi di crisi economica. Se un cliente decide di ridurre il budget di un progetto, agli sviluppatori viene spesso chiesto di consegnarlo prima, per restare nei costi previsti. Lavorare sotto stress e con tempi di consegna insensati non farà altro che aumentare la probabilità di ricorrere a scorciatoie poco sane per il progetto. Le conseguenze saranno anche sulla salute mentale del team. Un elemento che incide su concentrazione e produttività, non facendo che peggiorare la qualità del lavoro. Scrivere codice di scarsa qualità può portare a bug, problemi di sicurezza e costi aggiuntivi per l’azienda. Lavorare sotto pressione eccessiva, inoltre, può avere ricadute anche in termini di salute fisica e aumento dell’assenteismo.  

Se conta solo consegnare il progetto 

Quando le logiche di delivery prevalgono e non c’è consapevolezza sul debito tecnico, gli sviluppatori sono forzati a lavorare male. Le proprie competenze vengono degradate e non c’è niente che uccida di più la motivazione di un professionista. In pratica ti stai scavando da solo (metaforicamente) la fossa e lo sai benissimo. Perché tutto quello che dovrai fare su quel software sarà complicato. A meno di riscriverlo da zero con i giusti elementi. Ma questo richiederà tempo e budget che probabilmente il tuo CEO non è disposto a riconoscerti.  

Un freno alla crescita professionale 

Le competenze stesse del team in materia di linguaggi, infrastruttura, code design resteranno ingabbiate nei limiti di un codice di scarsa qualità, invece di evolvere naturalmente con il progetto. E se le skill non vengono aggiornate continuamente e messe in pratica, il proprio valore come professionista scenderà. 

 Insoddisfazione e turnover 

Il debito tecnico può avere ricadute pesanti sul morale degli sviluppatori. Un dipendente insoddisfatto è meno coinvolto nel lavoro e nel raggiungimento degli obiettivi aziendali. Non solo: in carenza di motivazione, viene meno anche la creatività e la capacità di proporre soluzioni e nuove idee. Una situazione del genere porta molti a cambiare azienda. E sappiamo bene quanto sia difficile trovare personale preparato nel settore IT. Ecco perché non ascoltare le richieste del team di sviluppo, non puntare su qualità e aggiornamento pesa sull’azienda anche a livello economico. 

Come evitare o ridurre il debito tecnico 

Le best practice per evitare il debito tecnico meritano un approfondimento a parte, su cui torneremo più avanti. Qui vogliamo evidenziare quelle che contribuiscono maggiormente a migliorare le condizioni di lavoro, il coinvolgimento e la motivazione degli sviluppatori.  

1. Definisci uno standard di sviluppo sostenibile 

Occorre innanzitutto stabilire linee guida chiare per scrivere codice che duri nel tempo, adottando metodi e approcci che rispondano a: 

  • Aderenza allo scopo e funzionamento del software  
  • Facilità di manutenzione e modifica  
2. Adotta un approccio agile e a micro-servizi 

Procedere a micro-servizi o con un approccio agile a piccoli rilasci continui è la cosa migliore da fare quando si tratta di affrontare di petto il debito tecnico. Sia a livello economico che umano. Questo perché permette di avere consegne più piccole, valutarle, validarle con il cliente e gestire il cambiamento se necessario 

Inoltre, usare un approccio di refactoring su piccole funzionalità, portandole a micro-servizi, stimola gli sviluppatori rendendoli più produttivi. Con il duplice vantaggio di svecchiare la codebase e identificare domini per isolare le responsabilità nel codice.   

3. Sconfiggi il “mostro” legacy con l’approccio strangler  

Lo strangler pattern è un metodo per sostituire gradualmente i sistemi legacy obsoleti con piccoli rilasci incrementali. I vantaggi sono diversi: 

  • permettere agli sviluppatori di riscrivere il codice di un componente alla volta, e rilasciare di volta in volta i nuovi servizi, senza dover mettere offline l’intera applicazione. 
  • non dipendere da possibile obsolescenza dei framework o delle tecnologie utilizzate 
  • abilitare un refactoring più veloce nel caso di gestione di cambiamenti di logica business (change management). 
4. Condividi skill e conoscenza nel team 

Incoraggiare condivisione di skill e ricerca della qualità all’interno del team può essere un motore di coinvolgimento e miglioramento potentissimo. Come? Richiedendo ad altri revisioni sul codice e sessioni di confronto per individuare e risolvere subito eventuali problematiche. E promuovendo il Test-Driven Development (TDD), ossia testando nuovi scenari prima di sviluppare funzionalità che effettivamente funzionino. 



Vuoi saperne di più sui nostri servizi?

Contattaci ora!

ELEVA Srl
Via Aldo Moro 5
27028, San Martino Siccomario (PV) - ITALIA
Email: info@eleva.it
Website: www.eleva.it

Privacy Policy
Cookie Policy

Codice SDI per la fatturazione elettronica: SZLUBAI