Technical debt

In un mondo perfetto non ci sono Technical Debt (TD). Ma noi non viviamo in un mondo perfetto e e questo non è un male!

Le (mie) tre vie al TD:

- Lo si compie inconsciamente e non lo si riconosce
- Lo si compie consciamente e lo si ignora
- Lo si compie consciamente, lo si valuta e lo si annota (è di fatto un bug)

Noi viviamo di TD perché se non ci fossero vorrebbe dire semplicemente che abbiamo costruito un sistema perfetto, che non esiste, quindi lo sforzo più grande è capire quando ci si deve fermare.

Un esempio di TD ambiguo é secondo legato agli aspetti di Premature Optimization (PO: la radice di tutti i mali); eppure nel fluire del codice dalla nostra mente al nostro editor di fiducia occorre ignorare il TD per non incorrere nella PO.

Certo identificare un TD a livello micro è forse scorretto e va contro la logica del TD, ma la stessa cosa si può applicare salendo di livello al design: se decidiamo di implementare una funzionalità utilizzando una tecnica semplice e inefficiente al posto di una complessa e efficiente (assumendo che l’efficienza sia un requisito) abbiamo un TD, d’altra parte sforzarsi prematuramente per rendere del codice efficiente già a partire dal design ritorna ad essere una PO.

La chiave di tutto deve naturalmente essere il contesto e l’analisi dei tradeoff che si hanno quando ci si trova a scegliere una strada piuttosto che un’altra quindi se da una parte occorre combattere l’ignoranza (propria o degli altri) che causa TD senza accorgersene, educare o educarsi all’analisi dei tradeoff è un requisito altrettanto fondamentale.



Inspired by:
http://blog.objectmentor.com/articles/2009/10/15/we-must-ship-now-and-deal-with-consequences
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
http://blog.objectmentor.com/articles/2009/09/22/a-mess-is-not-a-technical-debt

Must learn: tradeoff analysis