TRASFORMAZIONE DIGITALE E QUALITÀ DEL SOFTWARE
La qualità del software è una delle garanzie, quasi sempre disattese, nell’ambito dello sviluppo di un progetto di Trasformazione Digitale. La prima release di un progetto software è composta per il 70% dall’aderenza ai requisiti di business e per il 30% dalla sua qualità. Quest’ultima non è un esercizio stilistico, e già a partire dalla seconda e terza release le proporzioni percentuali cambieranno radicalmente spostando quasi tutta l’attenzione proprio sul valore, che si traduce in manutenibilità e capacità di adattamento.
Ciò significa che, superata la prima milestone di rilasci previsti, quasi tutta la partita si giocherà sul versante della funzionalità e dell’eleganza del codice (che tradotto significa codice leggibile e comprensibile da persone con un background di programmazione differente) e nondimeno dell’infrastruttura su cui esso poggia, elemento spesso sottovalutato perché più nascosto e inevitabilmente meno percepibile ai non addetti ai lavori.
Ogni volta che una feature viene implementata in un sistema informatico si generano delle dipendenze e interdipendenze, e uno degli obiettivi della progettazione software (di alto livello) è ridurre il numero di queste dipendenze rendendole più semplici e ovvie possibili.
Ma quando ci sono dipendenze o interdipendenze?
Si verificano quando un dato “pezzo di codice” non può essere compreso o modificato in maniera isolata, perché è in qualche modo correlato ad altro; il codice rispecchia processi operativi che per quanto riducibili a step o fasi sono spesso strutturalmente interdipendenti. Un workflow è composto da una serie di azioni che hanno un inizio e una fine e sono tra di loro collegate. Ad esempio, preparare un piatto di pasta ha come fasi il prendere la pentola, riempirla d’acqua, aggiungere il sale, accendere il fornello, selezionare il tipo di pasta, gettare la pasta al momento giusto e svuotare la pentola al momento opportuno in un dato recipiente che chiamiamo scolapasta.
A questo si aggiunge un ulteriore elemento che identifica la qualità del software, sto parlando del cosiddetto tasso di oscurità. L’oscurità si verifica quando le informazioni importanti non sono ovvie. Ad esempio, l’eccessiva astrazione nella scelta del nome di una variabile interferisce nella piena comprensione del suo riferimento. Oppure nella presenza di elementi incoerenti, quando la ripetizione del nome di una variabile per casi differenti rende difficile identificarne il suo impiego.
Arrivando al punto. La complessità, che farà lievitare i costi di manutenzione e gestione di una applicazione, si verifica perché centinaia, migliaia di piccole oscurità e dipendenze o interdipendenze si accumulano nel tempo. All’aumentare delle righe di codice, si amplifica e cresce la superficie di incognite e interdipendenze che porta, inevitabilmente, a interventi successivi volti a sistemare bug, rischiando anche di “rompere” altre componenti dell’applicazione, che condurranno a ulteriori bug; e avanti così.
La nuda verità è che la complessità renderà difficile, rischioso e nondimeno costoso modificare la base di codice esistente.
Sono diverse le organizzazioni che incoraggiano una mentalità tattica focalizzata sul far funzionare le feature richieste dal cliente il più rapidamente possibile, per massimizzare la resa in termini di “giornate uomo”. Questo è un approccio tipico di chi ha confuso lo sviluppo software con uno da catena di montaggio tipico delle fabbriche dell’era industriale analogica.
Se si desidera un buon design e una buona “postura” dell’applicazione è inutile sottolineare la necessità di adottare un approccio strategico che dia la priorità all’investimento di tempo, così da produrre progetti puliti e risolvere i problemi al principio. Un approccio di questo genere produce progetti migliori ed è a tutti gli effetti più economico di uno tattico a lungo termine.
Quest’ultimo ha come obiettivo primario far funzionare qualcosa, come una nuova feature o una correzione di bug. Se stai programmando tatticamente stai cercando di completare un’attività il più rapidamente possibile.
“BASTA CHE FUNZIONI” È UNA REGOLA CHE NON VALE
Alcuni clienti sono soddisfatti nel vedere tante “teste” (Full Time Equivalent – FTE) dedicate al progetto – questo figura una situazione prolifica che produce tanto codice velocemente – possibilmente tutte nella stessa stanza (Covid permettendo) a battere tasti chine sui propri terminali. Tra di esse c’è sempre un fenomeno che pigia i tasti più velocemente, e quando c’è da implementare una funzione “nessuno lo fa meglio di lui”.
In alcune organizzazioni i suddetti fenomeni vengono trattati come degli eroi, tuttavia queste figure, e con loro il resto del nutrito team che per correre a velocità sostenute brilla in scarsa comunicazione, lasciano alle loro spalle un gran numero di problemi irrisolti.
Risultato? Chi dovrà lavorarci in futuro si troverà di fronte a delle black-box sulle quali sarà estremamente difficoltoso intervenire.
A questo punto avrai compreso come avere del codice funzionante non sia sufficiente. La maggior parte del codice in qualsiasi sistema è scritta estendendo la base di quello esistente. Il nostro lavoro come sviluppatori di software eccellente è facilitare la scalabilità futura del sistema stesso. Pertanto, non vale la regola del “basta che funzioni”, anche se ovviamente deve funzionare.
L’obiettivo di una Azienda che sviluppa software nel 2021 dovrebbe essere quello di produrlo con un ottimo design, che realmente funzioni.
Un approccio che richiede all’organizzazione di sviluppare una mentalità ad investimento, in grado di dare al software una postura corretta dedicando il tempo necessario alla fase di start up per poterne poi beneficiare negli sviluppi futuri. Di conseguenza, si va ad evitare il problema della Broken Window Theory, che per essere contrastato richiede refactoring continuo (“prevenire è meglio che curare”, lo dicevano già gli antichi greci!), lasciando lo spazio a implementazioni a basso effort.
Il nostro approccio si basa sul muoverci sì velocemente, ma con una postura e una struttura solida e con un criterio modulare finalizzato alla riduzione della complessità. L’era del “Move fast and break things”, famoso motto di Facebook è finita, il Minimum Viable Product va sostituito dal Minimum Virtuous Product che si definisce con un più solido “Move Fast With Stable Infra”.
PERCHÉ PARLARE A SLOGAN NON SERVE
Lanciare degli slogan quando si parla di Digital Transformation è utile per fare un talk, mentre implementare software innovativi è tutt’altra cosa. Le persone che presentano la Trasformazione Digitale come un processo fast & simple invocando qualche frase fatta, molto probabilmente non hanno mai implementato alcun sistema complesso.
I progetti software sono progetti di ingegneria che tentano di risolvere e concretizzare soluzioni complesse, il problema è che spesso gli ingegneri sono dei grandi ottimisti e quasi sempre i tempi di esecuzione si raddoppiano o triplicano rispetto alle stime effettuate. Una situazione del genere si è già verificata nei secoli passati, prendiamo ad esempio il ponte di Brooklyn, lo stesso si può facilmente verificare anche per lo sviluppo di un software, ma con una ulteriore incognita: il lavoro cognitivo è assimilabile a un essere vivente, non è un oggetto inanimato e fisso. Il risultato, quindi, non potrà che essere un sistema organico in continua evoluzione.
La Trasformazione Digitale è destinata a sconvolgere ulteriormente il nostro mondo producendo cambiamenti di business epocali. Più tempo sprechi nell’attesa di affrontare i problemi di progettazione di un software, più grandi questi diventano.
Le soluzioni saranno sempre più impattanti sia a livello di applicazione, che a livello di organizzazione, sempre in termini di complessità. Tutto ciò renderà più naturale continuare a rimandare, con il risultato di perdere il vantaggio competitivo sui competitor, che nel frattempo han lavorato con giudizio, relegandoti, nel migliore dei casi, a semplice follower.
TI È PIACIUTO QUESTO ARTICOLO? LEGGI ANCHE:
Trasformazione digitale efficace: strategia, non tecnologia da videogioco
4 keyword per la Business Transformation
Come diventare un supereroe del business in 3 giorni
