Critical Mass of Software System, ovvero il fattore di complessità che separa la convenienza di manutenere ed estendere il sistema con quella di riscriverlo interamente.
Per quanto poco noto come nel mondo informatico, il concetto di Massa Critica è sicuramente un elemento di management di forte significato, in grado di scatenare dinamiche di gestione non indifferenti. Si tratta, infatti, di determinare se, su un dato sistema, è ancora economicamente conveniente effettuare manutenzione evolutiva piuttosto che procedere ad una sua completa riscrittura.
Figura 1 - Critical Mass
Quello che emerge in modo empirico (e statistico) è che tanto migliore è la qualità della soluzione realizzata (sia da un punto di vista della codifica che dell'ALM), tanto più si riesce a deferire nel tempo il punto di Massa Critica, traendo maggior Valore dall'investimento fatto (ROI) e spalmandone il costo di gestione (TCO) su un periodo di più lunga durata.
In questo contesto, l'adozione di pratiche Agile consolidate come Continous Integration, favoriscono la qualità della soluzione che si sta realizzando. Inoltre, una corretta applicazione di una specifica metodologia, consente di mitigare il problema del Technical Debt (Debito Tecnico), che, nel medio periodo, porta ad una rincorsa continua della manutenzione correttiva a scapito di quella evolutiva.
Si intuisce agevolmente come l'utilizzo delle "pratiche di qualità", tipiche del mondo Agile/Lean, permettano di appiattire la curva dei costi della manutenzione evolutiva, mantenendo decisamente marcato il delta rispetto a quello di riscrittura (fig. 2). Parliamo ovviamente di: continuous integration, test-driven-development, behaviour driven development, continuous refactoring, ecc.
Figura 2 - Ritardare il punto di Massa Critica7
Soffermandosi un attimo sulla figura 2, nelle prime fasi si nota una condizione curiosa: il costo di riscrittura è minore di quello di evoluzione, come mai? Il motivo è abbastanza semplice ed è da ricercarsi nell'Effort necessario ad implementare l'infrastruttura di supporto alle attività di manutenzione, come, ad esempio, le utility del sistema di ALM incaricate del testing automatizzato.
Nella realtà, per quanto si voglia gestire il debito tecnico accumulato, ne esiste sempre un certa percentuale che si decide di tollerare onde evitare che il delivery del progetto si protragga troppo nel tempo. Tipicamente, i Team decidono, ad intervalli più o meno cadenzati, di gestire o trascurare momentaneamente il debito tecnico accumulato, creando un effetto molla che, visivamente, trasforma il grafico precedente come segue:
E' subito evidente che in questo scenario la condizione precedentemente illustrata (riscrittura inizialmente più conveniente dell'evoluzione) scompare immediatamente.
Realisticamente, oggi, non è possibile effettuare una stima di quando si raggiungerà il punto di Massa Critica, essendo i fattori che lo determinano praticamente non quantificabili. Se anche provassimo a fare un tale esercizio, chi ci dice, ad esempio, che in un certo istante T il successo della nostra soluzione sia tale da trasformare il Team con nuove competenze stravolgendo, di fatto, quanto ipotizzato?
D'altro canto, però, il concetto di Massa Critica è sicuramente utile a giustificare l'investimento nelle suddette pratiche di qualità e nelle metodologie Agili, soprattutto se abbinato all'esperienza accumulata, dove pesano, soprattutto, i fallimenti e l'impossibilità di sfruttare fino in fondo gli investimenti fatti sulle precedenti attività di sviluppo.
