Ci sono periodi ricorrenti nel mio lavoro, che di tanto in tanto si ripropongono presentando analoghe domande cui spesso si dimentica di aver già dato risposta precedentemente. Capita così che periodicamente si ripresenti la necessità di iniziare ex-novo un progetto, sul quale l'azienda ha deciso di investire del tempo, e con l'occasione ci si ritrovi nuovamente di fronte alla domanda: e adesso da dove cominciamo?
E' tempo di Analisi, e non mi riferisco a quella, abitudinaria, acquisita, normale, routinaria di tutti i giorni, quella che serve a precisare i dettagli che di volta in volta si rivelano e a smussarne gli angoli per trovare la giusta collocazione ai problemi, ma piuttosto a quella in cui ci si trova di fronte una montagna e si deve decidere da che parte prenderla per arrivare con successo in vetta.
Personalmente ritengo esista una sola strada per giungere al successo e tale strada comporta lo "sbriciolare" la montagna dapprima in macigni, poi in zolle, e così via fino alla pietruzza che rappresenta l'unità ultima analizzabile, l'atomo del problema, che si può facilmente comprendere in tutti i suoi aspetti e dare ad esso una soluzione certa. Questo consente di avere chiaro quale sia il dominio con cui si ha a che fare - le entità e gli attori che entrano in gioco - il creare un modello ad oggetti stabile che possa servire da base per tutte le componenti del sistema e a decidere poi quali parti approcciare prima e quali dopo con piena coscienza del problema che si sta affrontando e magari con un metodo iterativo che permetta di raffinare le varie parti un po' alla volta.
Non di rado mi capita di scontrarmi con approcci diversi, sbrigativi e un po' miopi. Purtroppo accade troppo spesso che il costo dell'analisi sia considerato superfluo, o comunque non remunerativo, e quindi invece che cercare di investire bene il poco tempo disponibile si cerchi di trovare delle scorciatoie che lasciano grandi margini di errore e di conseguenza penalizzano a lungo andare l'intero progetto. Così magari si dimentica che una visione globale di ciò che si deve realizzare consente di risparmiare tempo progettando le parti del software che dovranno essere riutilizzate, che definire i limiti di ogni singola componente impedisce di trovarsi a sviluppare due volte la stessa cosa. Così semplicemente si vede un "comignolo" che pare semplice da realizzare, o magari conveniente, e si decide di cominciare da quello dimenticando che di solito le case come i software si costruiscono a partire dalle fondamenta. Risultato di tutto ciò è un software che non ha architettura, un patchwork di microsoluzioni che fanno a pugni le une con le altre e che a lungo andare causano una crescente "entropia" che rende impossibile evolvere ulteriormente la soluzione.
Di software così ne ho visti molti, e non nego di aver commesso io stesso errori del genere in "giovinezza", ma la mia scelta ormai ricade invariabilmente sulla comprensione, sulla conoscenza del problema che solo una analisi ben fatta può fornire. E così ogni volta che ricomincio, di solito cerco di farlo con metodo e costanza, e se mi chiedono un consiglio quello che dico non è ne più ne meno di quello che sto scrivendo... ma poi ogni volta, qualcuno che vuole fare il furbo lo trovi... chissà perchè...