Indice
In questa puntata si parla del dilemma che prima o poi mette in difficoltà qualsiasi CTO (ma anche Founder di Startup e manager), e cioè quello di decidere se riscrivere da capo la propria piattaforma o provare a sistemarla quando i problemi iniziano ad essere troppi e risolverli diventa sempre più costoso.
Il sito di cui si parla nella puntata si trova nella pagina dedicata al GamePlan Check Up.
Clicca il tasto play nel player qui sotto per ascoltare subito questa puntata del podcast.
Trascrizione
Ciao da Alex Pagnoni e benvenuto nel podcast dedicato ai CTO e ai responsabili dei team di sviluppo, a chi vorrebbe diventarlo e a Founder e imprenditori digitali.
In questa puntata tratterò il dilemma che prima o poi mette in difficoltà qualsiasi CTO, e cioè quello di decidere se riscrivere da capo la propria piattaforma o provare a sistemarla.
Infatti uno dei problemi principali nello sviluppo e nella gestione di un prodotto digitale è il fatto che nel momento stesso in cui rilasciamo la prima versione del nostro prodotto o piattaforma, questa in un certo senso diventa automaticamente un legacy.
Non nel senso che è obsoleta o datata, ma che diventa immediatamente una base di codice che deve essere mantenuta e che per tanti motivi è destinata quasi sempre a peggiorare nel tempo, al di là delle migliori intenzioni del team di sviluppo.
Inoltre in molti casi il prodotto potrebbe anche essere stato scritto male fin dall’inizio, ad esempio per via di scelte architetturali errate, per inesperienza del team di sviluppo, per errori manageriali, troppa fretta nel cercare di uscire sul mercato il più velocemente possibile, stime sbagliate che portano poi a dover prendere scorciatoie e saltare ad esempio i test unitari e funzionali, persone chiave che cambiano all’improvviso e così via.
E se anche così non fosse, se il prodotto è destinato a durare nel tempo, e per esperienza so benissimo che molti prodotti digitali durano più del tempo preventivato inizialmente, è del tutto probabile che nel tempo potremmo non avere più a disposizione i Product Owner o gli sviluppatori originali, che magari nel frattempo sono stati ruotati in altri ruoli senza un opportuno scambio di know how o hanno persino cambiato lavoro.
Oltre a questi fattori, la stessa fase di manutenzione è facile che introduca nuovi tipi di problemi e soprattutto debito tecnico, in più la manutenzione è spesso più noiosa per i programmatori rispetto allo sviluppo di qualcosa di nuovo partendo da zero e questo può facilmente far sì che ci sia meno attenzione nell’utilizzare le pratiche di sviluppo migliori.
In più, nel frattempo le tecnologie e gli strumenti di lavoro non fanno altro che cambiare ed evolvere e potremmo ritrovarci con una base di codice funzionante in modo accettabile ma basata su tecnologie non più supportate.
Basti pensare a quanto poco tempo ci è voluto per passare prima dalle applicazioni desktop alle applicazioni web, poi alle applicazioni mobile, alle progressive web applications, oppure dal caro vecchio ferro alle macchine virtuali, al cloud computing fino al serverless, e così via.
Quindi è abbastanza scontato che ad un certo punto ci si ritrovi nella condizione di chiedersi se è ora di riscrivere tutto da capo oppure se fare refactoring.
Per quanto riguarda quest’ultimo, non intendo il refactoring sistematico che andrebbe comunque fatto adottando ad esempio tecniche di sviluppo come il TDD, mi riferisco invece al ristrutturare più o meno pesantemente l’applicazione anche sugli aspetti architetturali e strutturali per darle un nuovo aspetto e ammodernarla o renderla più mantenibile.
In generale bisogna valutare attentamente la situazione in cui ci vuole più tempo e impegno di quanto necessario per sistemare un bug o introdurre una nuova funzionalità a causa del debito tecnica, situazione questa in cui il software diventa sempre più difficile da mantenere.
In molti casi come questi apportare modifiche è davvero un problema e magari come tocchiamo una parte se ne spacca un’altra, perché non ci sono nemmeno i test automatici.
Questa è una situazione in cui scatta l’allarme che può portare a valutare una riscrittura o un refactor.
Questa situazione peraltro è ancora più evidente quando un team di sviluppo diverso da quello originale si ritrova a prendere in carico un’applicazione esistente, ad esempio quando subentra un nuovo fornitore.
In questi casi avviene spesso che i programmatori ci dicano che la base di codice è una porcheria e che andrebbe riscritta da capo, e spesso nessuno vuole metterci mano.
Peraltro questo è aggravato da quanto dicevo prima, cioè che giustamente ai programmatori piace di più tendenzialmente scrivere qualcosa di nuovo con le ultime tecnologie e metodi di lavoro che non metter mano a codice di altri reputato schifoso o complicato.
E qui è facile sparare sul lavoro fatto da altri, per vari motivi tra i quali il fatto che in realtà leggere il codice è per molti versi più difficile che scriverne di nuovo.
Questo infatti è uno dei motivi per i quali ogni programmatore ha alla fine il suo set di codice scritto a modo suo per problemi già risolti tantissime altre volte e magari anche meglio da altri programmatori e già resi standard in forma di componenti o librerie anche open source.
Non parliamo poi dei casi in cui abbiamo a che fare con i classici programmatori definiti rock star dello sviluppo, per i quali qualsiasi altra cosa fatta da altri è fatto male.
Guarda caso però si tratta quasi sempre delle stesse persone che non hanno mai riscritto da capo qualcosa, perché chiunque l’abbia fatto sa quante insidie si nascondo dietro una riscrittura completa e in generale cerca di evitarla.
In generale la riscrittura da capo di un prodotto digitale è qualcosa che viene quasi sempre sottostimata, innanzitutto dai programmatori ma anche dal management.
Quindi un CTO che non ha mai guidato un processo di riscrittura completa di un software dovrebbe fare molta attenzione prima di sponsorizzare un’operazione simile, va ponderata moltissimo.
Quasi sempre parliamo di software dove abbiamo accumulato anni di requisiti, sviluppi, ragionamenti, bug fix relativi alle condizioni più disparate e strane, cambiamenti, integrazioni esterne, ecc. e ricostruire tutto da capo può essere una sfida titanica dove è decisamente difficile riuscire a reintrodurre tutto e per bene con successo.
E se abbiamo appunto dedicato molto sforzo e tempo, significa che l’azienda ha già fatto un investimento enorme per un prodotto che ha generato valore, anche perché se non lo avesse generato probabilmente non parleremmo neanche di sistemare o riscrivere, ma lo dismetteremmo via direttamente.
Chiaramente non è affatto bello gettare via anni di investimento e più l’applicazione è grande e maggiore è il tempo e il denaro necessario per ricostruirla.
E soprattutto andiamo a destinare ingenti risorse nel riscrivere da capo, sottraendole dalla manutenzione della versione già esistente che rischia di rimanere ferma e generare a questo punto altri tipi di problemi.
Tutto ciò nell’attesa della riscrittura di un sistema che può durare mesi se non anni, mentre magari nel frattempo avvengono cambiamenti importanti nel mercato ai quali dobbiamo rispondere rapidamente quando invece ci siamo impiccati con una riscrittura completa che richiede ancora parecchio tempo per uscire.
E’ chiaramente molto meno rischioso ristrutturare una piattaforma già esistente e farla sterzare rapidamente nel momento in cui ci sono nuove situazioni nel mercato.
Mi ricordo ad esempio quando la Netscape aveva dedicato 3 anni per riscrivere da capo quello che era il principale browser nel 2000, mentre nel frattempo altri browser l’avevano soppiantato decretandone il fallimento.
Detto questo, non c’è una riposta definitiva e universale per tutti i casi, ma in generale quello che raccomando sulla base di quanto ho appena descritto è di cercare di recuperare quanto già esistente portando avanti un progetto di refactoring studiato per bene.
Sono veramente poche le volte in cui un CTO mi ha chiesto un suggerimento o un cliente mi ha sottoposto la sua situazione in cui ho consigliato di riscrivere da capo, invece dopo aver analizzato e approfondito la situazione ho quasi sempre indicato di prendere la strada del refactoring.
Che poi dal mio punto di vista quello di un progetto di refactoring è comunque qualcosa di entusiasmante se preso nel verso giusto dagli sviluppatori, perché consente di trasformare qualcosa di già esistente e farlo evolvere in una nuova creatura migliore, applicando tante tecniche di refactoring che possono essere viste come una sfida molto interessante da cogliere.
Si possono anche elaborare soluzioni tecnicamente interessanti e strutturate, ad esempio in Axelerant molte volte ci è stato chiesto di procedere con un refactoring massivo e nel caso ad esempio delle applicazioni PHP impieghiamo una strada che porta a incastonare il codice legacy dentro Symfony con una sorta di ponte tra legacy e nuovo, per poi far assorbire man mano il codice vecchio dentro Symfony e al contempo mantenere e sistemare la parte legacy.
L’unico vero caso in cui invece è chiaramente necessario procedere con una riscrittura completa è quando la tecnologia o il linguaggio sottostante diventano del tutto obsoleti o non più supportati e al contempo è previsto ancora molto tempo utile nel ciclo di vita dell’applicazione.
Ad esempio ho un cliente che aveva una grossa applicazione sviluppata in Visual Fox Pro, che ad un certo punto come linguaggio è morto e non è più stato supportato dalla Microsoft, e in quel caso è stata l’occasione utile per cambiare paradigma e andare verso la strada della scrittura di un’applicazione erogata in modalità SaaS.
Per gli altri casi invece generalmente analizzo la situazione, verifico codice e infrastruttura con il mio team e quasi sempre nel report finale indico la strada del refactoring e quali sono le linee guida che deve seguire chi si occuperà del refactoring per avere successo.
Ad esempio se mancano i test funzionali, quello di scriverne man mano un buon numero è uno degli investimenti principali per ridurre di molto i problemi del refactoring e che poi avrà grande utilità anche nella versione ristrutturata.
Grazie per aver ascoltato questa puntata del podcast dedicata a come scegliere tra refactoring e riscrittura completa.
Se vuoi approfondire questo argomento o vuoi riportare la tua esperienza, oppure se vuoi suggerire un argomento per le prossime puntate, puoi scrivere nel gruppo Facebook del podcast cercando CTO Mastermind su Facebook.
Se hai bisogno di capire se anche nel tuo caso è ora di metter mano al codice del tuo prodotto o servizio digitale, oppure se sei già nella situazione di decidere se procedere con il refactoring o la riscrittura e nel caso come procedere, oppure se hai bisogno di un team di sviluppo che esegua il refactoring o la riscrittura per te, ho creato un servizio apposito dove interverrò io personalmente assieme al mio team di sviluppo.
Vai sul sito GamePlan Check Up per chiedere di essere contattato per avere maggiori informazioni senza impegno, puoi trovare il link anche nella descrizione di questa puntata del podcast.
Nei prossimi episodi parlerò di vari argomenti tra i quali quello del debito tecnico, che ho citato prima quando ho elencato i vari fattori che portano a scegliere tra refactoring e riscrittura e che possiamo riscontrare in tutti i prodotti e servizi digitali, quindi un’altra spina nel fianco per CTO e responsabili aziendali.
Grazie di nuovo e alla prossima puntata, ciao da Alex.
