-
Cos’è per te il debito tecnico? Come lo definisci e, soprattutto, che effetti ha nella tua esperienza?
-
Una volta constatato che nella tua applicazione esiste del debito tecnico, cosa fai per ridurlo? Ci sono delle pratiche o degli strumenti che nella tua esperienza si sono rivelati particolarmente utili?
-
Uno dei problemi principali del debito tecnico è probabilmente la difficoltà di comunicarlo a persone che non hanno un background tecnico. Ti è capitato di scontrarti con questo problema? Come l’hai risolto? Che altri problemi ti è capitato di affrontare nella gestione del debito tecnico?
-
Quale lettura ha influenzato la tua visione del tema del debito tecnico o ti ha aiutato ad approcciare meglio il problema?
Organizzazione
Insieme di risorse (denaro, persone) che agiscono col fine di raggiungere un obiettivo in comune, spesso economico.
Il software è lo strumento col quale perseguire tale fine, eventualmente producendo del valore.
Debito tecnico
E' la distanza (disagreement) fra i bisogni/richieste del business e l'attuale stato del softare.
Il costo extra in termini di tempo e risorse impiegate per sviluppare una funzionalità richiesta dal business è il pagamento degli interessi del debito.
Tipi di debito
- Spericolato e deliberato: non abbiamo tempo per trovare un design migliore per modellare il problema
- Spericolato e involontario: var a = 1, cosa vuol dire?
- Prudente e deliberato: Rilasciamo la funzionalità e rifattorizziamo
- Prudente e involontario: dopo diverso tempo abbiamo capito come doveva essere fatto
Cause del debito
- Design del sistema errato. Molto comune, considerando che lo sviluppo software è un continuo imparare rispetto al problema, o dominio, che si sta modellando
- Pressione costante e tradeoff fra qualità e velocità nel rilascio delle features
- Cambiamento costante dei requisiti del software
Side effects
- Rallentamento nello sviluppo di nuove funzionalità
- Bancarotta: il costo per migliorare o modificare il software necessari a implementare nuove funzionalità è superiore a quello richiesto da una riscrittura del software.
- Stress, Turnover: nessuno vuole lavorare su un software di pessima qualità, o di cui nessuno comprende il funzionamento
Soluzioni
- Spendere più tempo nella fase di design, per meglio comprendere i requisiti del software e il dominio applicativo. Si noti che il tempo investito in design ha un rendimento decrescente, poichè ingegnerizzare troppo rende il sistema poco flessibile rispetto al cambiamento.
- Adottare processi che permettano cicli di sviluppo rapidi: implementazione, learning, refactoring.
- Tracciare, descrivere e prioritizzare il debito tecnico in modo che non ne vada persa traccia.
- Best practices: TDD, clean code, Continuos Integration and Deployment
- Debt Metaphor Ward Cunningham
- The true meaning of technical debt Luca Rossi
- A Mess is not a Technical Debt Uncle Bob
- Technical Debt Martin Fowler
- Technical Debt Quadrant
- Is High Quality Software Worth the Cost? Martin Fowler
- Technical debt as a lack of understanding Dave Rupert
- An exploration of technical debt Edith Tom, Aybüke Aurum, Richard Vidgen