Quando non basta un'ascia ben affilata

Se avessi a disposizione otto ore per abbattere un albero, ne passerei sei ad affilare l’ascia (A. Lincoln)

Molti anni fa, mi fu offerto di rifare completamente un gestionale interno per un'azienda delle mie parti. Avrei avuto la possibilità di scegliere io gli strumenti o quantomeno di influenzarne pesantemente la scelta.

Ero eccitatissimo all'idea, per una sfida che ero sicuro di centrare, sarebbe stato, pensavo, un successo, finalmente la possibilità di fare qualcosa di grande e di fare il salto di qualità che cercavo.

Per una missione così importante, pensai bene che gli strumenti che avevo usato fino a quel momento non fossero indicati e ancor oggi credo che questo fosse giusto.

Mi informai presso degli amici che lavoravano in città di quale database avessi potuto dotarmi per quell'impresa, senza legarmi a un particolare sistema operativo, perché già allora mi ero avvicinato a Linux e all'open source. Inoltre avevo già studiato i primi rudimenti di Java e di programmazione a oggetti e mi sentivo quasi pronto.

Mi fu consigliato DB2 UDB versione 5 di IBM. Come IDE pensai a Jbuilder 3 Enterprise dell'allora Borland. Avevo a disposizione il budget e degli strumenti di classe enterprise, tutto ciò che avevo chiesto l'avevo ottenuto.

Fu una catastrofe.

Una lezione che imparai col tempo è che una lenta evoluzione è sempre preferibile a una sanguinosa rivoluzione e che quando è proprio necessario buttare via uno strumento intero, si tratta di una situazione veramente grave per chi ha fatto le scelte precedenti. Spesso poi chi fa la nuova versione si trova nel bivio se portare avanti anche i bug o quantomeno i comportamenti sbagliati del programma precedente o se cambiare strada, anziché fare "semplicemente" un porting come previsto.

JBuilder 3 era una cozzaglia di bug, indegno del nome dell'azienda che lo aveva creato e che  aveva una forte tradizione negli ambienti di sviluppo. Le versioni successive erano migliori, ma chi era rimasto scottato da quell'esperienza aveva probabilmente messo una croce sul nome Borland, che dopo pochi anni, guarda caso, cedette gli strumenti di sviluppo ad altri.

Il mio errore? Non averlo provato a sufficienza senza dubbio fu uno sbaglio di inesperienza, ma l'errore più grave fu non chiedere prima al cliente, con una demo magari, se i controlli presenti nell'IDE e completamente proprietari di Borland, avevano un comportamento accettabile per lui e cos'altro avrebbe desiderato.

Fu un'errore che mi costrinse in corso d'opera a cambiare completamente il framework, per SWING. Chiunque abbia sviluppato con SWING sa di cosa parlo...

DB2 era il database di una multinazionale che aveva fatto la sua fortuna sui progetti di gestione dei dati. Aveva funzionalità avanzatissime quali la possibilità di gestire le dimensioni dei pool di pagine del disco, ripartizione delle tabelle, gestiva query lunghe diverse pagine senza problemi, gestiva partizioni sul disco proprietarie saltando il sistema operativo E NON PERMETTEVA DI CANCELLARE UNA COLONNA.
Mi sembrava incredibile, ma bisognava esportare i dati, togliere le integrità referenziali, cancellare la tabella e reimportare i dati senza la colonna, poi ricreare le integrità ecc...
Il cliente era tra il furibondo e lo scoraggiato. Io non riuscivo a darmi una spiegazione ed ero mortificato. Seppi poi che la versione per AIX (io usavo quella per windows NT) non soffriva di questo problema. Una mossa "commerciale" di IBM per penalizzare l'uso di proprio prodotti sulle piattaforme concorrenti? Una sorta di castrazione insomma...

Si trattava di uno strumento rigidissimo, sviluppatosi in contesti dove le specifiche sono scritte nel marmo, mentre una piccola impresa invece vive d'agilità.
Aveva anche dei bug sottili, come il fatto che quando si faceva un restore su una macchina diversa con partizioni gestite direttamente, la nuova partizione doveva essere un pelino più grande, altrimenti il restore non funzionava. Inoltre c'erano altri piccoli comportamenti fuori standard con Java che lo rendevano imprevedibile, fino a quando non si sapeva che fare.

Se avessi fatto un programma più piccolo ma completo prima, forse avrei parato molti colpi, ma il problema principale fu che uno strumento così difficile ha senso soltanto per chi ha contratti di supporto e fa corsi o è inserito in una cerchia di consulenti che lo conosce, magari legati al produttore. La mia ignoranza su DB2 la pagai con il dovere risolvere in fretta problemi sul campo e quel progetto mi fece invecchiare presto. Ancora più grave fu il rapporto di fiducia irrimediabilmente incrinato con chi si aspettava che sarebbe stata una passeggiata e aveva pagato profumatamente quegli strumenti.

DB2 era su un livello qualitativo ben superiore all'IDE che avevo scelto, ma in quell'ambiente e con la mia inesperienza, non era proponibile.
L'aggiunta di problemi con gli strumenti è una vera condanna per un progetto, perché oltre ad avere tempi lunghi, agli occhi dei clienti la colpa ricade sulle nostre capacità.

La paura, madre di ogni freno, fa si che molti scelgano di usare strumenti vecchissimi (si vede ancora in giro del vecchio Visual Basic 6) con la conseguenza che dopo un po'... il nostro software non gira più sui nuovi sistemi... miracoli del consumismo tecnologico.

Soltanto una perfetta padronanza degli strumenti assicura di potersi concentrare sulle esigenze (e sulle convinzioni) dei clienti, i quali prima di tutto devono potersi fidare di noi.

Credo che oggi non rifarei gli stessi errori. (!)