Sviluppare in COBOL può essere divertente

C’è molto più in una azienda, OLTRE la tecnologia

Come sviluppatori, tendiamo a dare molto peso alla tecnologia adottata da un’azienda, quando valutiamo una possibile collaborazione. Putroppo una decisione limitata a quest’ aspetto è troppo superficiale.

E’ la vecchia tecnologia ciò che temiamo? O Forse la cultura aziendale che è più immediato associarvi?

Voglio raccontarvi la mia storia, e quello che mi sarei perso se avessi riufiutato di lavorare in COBOL nel 2010, all’età di 25 anni.

Big city life

Finita l’università, iniziai a lavorare in una grossa azienda di Milano. Contribuivo alla scrittura di un social network ad uso aziendale, sul più recente stack Java del tempo. Tecnologie in trend in un mercato anch’esso in trend. Anche l’ambiente di lavoro era molto buono.

Sfortunamente, dentro, non stavo bene. Sono nato in Valcamonica, tra le montagne e la vita di città non faceva per me.

Sapevo di un compagno di università che lavorava per una azienda produttrice di software in Valle. Ottenni un colloquio e accettai l’offerta. Erano i leader nel loro mercato. Tuttavia c’era un difetto… il core business era basato su di un software scritto in COBOL.

Alcuni dei colleghi di Milano mi domandarono se fossi pazzo. Temevano che il mio valore di mercato ne avrebbe risentito, negli anni. Seppur il timore fosse lecito, fortunatamente non li ascoltai.

Vuoi qualche numero riguardo al COBOL?

Sappiamo già tutti quanto questo linguaggio sia tutt’oggi in uso. La pandemia non ha mancato di ricordarcelo, tramite le vicende negli Stati Uniti.

Tuttavia, questo è irrilevante ai fini del mio racconto. Non voglio convincere nessuno che il COBOL sia figo, perchè non lo è. E’ probabilmente il peggior linguaggio con cui abbia lavorato (dal punto di vista tecnico).

Quali caratteristiche lo rendono tanto brutto? E perchè gli sviluppatori non gradiscono lavorarci?

Quali sono i problemi?

Provo a a fare un elenco di situazioni con cui ho avuto a che fare, che solitamente un programmatore preferirebbe evitare:

• file sorgenti con più di 70000 linee di codice. Tanti!
• Nomi criptici di variabili, procedure e file. Anche se a volte molto divertenti, ad esempio: button-slarga (dialetto bergamasco/bresciano), libwinselsin, motor.ini 😂.
• UI obsoleta e molto limitata.
• Tipi di dato atipici (non si usano int,float,double,stringhe,char etc.).
• Non c’è supporto alla creazione di nuovi tipi di dato.
• Non ci sono librerie di strutture dati (ad esempio array dinamici, dizionari, linked list etc…).
• Non esistono le funzioni, e gli scope di allocazione.
• Persistenza proprietaria e obsoleta.
• Non ci sono framework di test (TDD style s’intende) .
• Programmazione procedurale.
• Devo continuare oppure ho reso l’idea? 😅

Cambio di prospettiva

Primi di chiederci “dove siamo finiti?”, facciamo un bel respiro e riguardiamo quella lista. Però cambiando punto di vista.

I punti dell’elenco sono problemi solo se sono accompagnati dalla frase seguente:

Qui abbiamo sempre fatto così

Questa frase è l’unica cosa che dovete assolutamente mantenere al di fuori della vostra vita lavorativa. E’ il peggior sintomo della paura del cambiamento.

Se invece lavorate con persone che accolgono il cambiamento, quella lista non riporta problemi, bensì un lungo elenco di opportunità.

Un ambiente fertile

Quest’ immagine è una bella metafora di un progetto legacy, gestito da persone con un buon mindset. Una vecchia casa, in un ottimo ambiente, dove ogni contributo sarà apprezzato. E ci sono un sacco di modi di rendersi utili.

Non esiste una libreria per la gestione di array dinamici? Chi ci vieta di farne una? Quanto spesso capita l’opportunità essere autori di una libreria di così basso livello, e di vederla andare in produzione? Quest’ occasione l’ho vissuta, e ad oggi la libreria che scrissi nel 2011, conta circa 24000 riferimenti in quasi 2000 sorgenti. Esiste una sua versione open source.

IDE obsoleta? Un collega ha creato un’estensione per VS Code. Tutto il team l’ha adottata, ed è incredibilmente migliore rispetto all’IDE ufficiale.

Vi propongo un’altra lista. Alcune delle sfide più interessanti che abbiamo avuto occasione di affrontare:

• Una libreria per gestire scope di allocazione di risorse (garbage collection)
• Una nuovo sistema di persistenza, specializzato sul caching.
• Design del sistema di gestione di errore, ispirato alle eccezioni OOP.
• Un server per esposizione di API del gestionale legacy.
• Design e implementazione di funzionalità comuni delle griglie (la componente UI fornita, non ha nemmeno le colonne ordinabili).
• L’adozione di un sistema di versionamento e il successivo passaggio a Git.
• La transizione alle metodologie agili.
• E tante altre… la lista sarebbe veramente lunga.

Dobbiamo sempre tenere a mente che i limiti sono degli strumenti, non nostri.

COBOL è scarsamente supportato dalla community, di conseguenza è frequente la situazione in cui la domanda non è “Che framework/libreria/tool uso?”. La domanda è “Che framework/libreria/tool costruisco, e come?”. Per certi versi è anche più rilassante, rispetto a trovarsi a sguazzare nella giungla dei framework dell’informatica moderna.

Avevo un sogno

All’università mi specializzai nella Computer Vision. Sognavo di lavorare un giorno in questo settore. Tuttavia avevo il desiderio di continuare a vivere in Valcamonica, che non è esattamente la Silicon Valley.

 

Alla fine però, questo è proprio quello che è successo.

Abbiamo una serie di prodotti  “satellite” che integrano il prodotto principale scritto in COBOL. La maggioranza di questi, sono scritti in C#. Uno di questi, ha la funzione di automatizzare il data-entry di un particolare tipo di documenti, acquisendone le scansioni. E’ da sempre un prodotto strategico per l’azienda, tuttavia la produzione era presso terzi. I costi erano molto elevati e il fornitore era, diciamo… “problematico”.

I capi decisero di riscrivere questo prodotto da zero, internamente. L’attività venne assegnata a me, e io ne fui ovviamente molto felice.

Questa fu una decisione da pazzi molto coraggiosa. Se avessimo fallito, avremmo perso una posizione di mercato strategica.

Fortunatamente andò bene. Il successo di quest’operazione non fu dovuto al fatto che fui in grado di scrivere un software con un livello di riconoscimento sufficiente. Avrei fallito se fossi stato da solo. Fu lavoro di squadra.

Stavamo sostituendo un prodotto con un livello di affidabilità di riconoscimento davvero elevata. Anche in caso di documenti ridotti molto male e scansioni di bassa qualità. Le prime installazioni pilot, fecero emergere non pochi problemi, tuttavia nessuno me ne fece una colpa. I miei compagni di team si occuparono di attutire i colpi che arrivavano dall’esterno, mettendomi nelle condizioni di risolvere i problemi, uno dopo l’altro. I “compagni di team” non erano solo altri sviluppatori, ma anche manager, PO e help-desker.

Se avessi rifiutato di lavorare con queste persone solo perchè utilizzano COBOL, avrei perso l’occasione di lavorare su ciò che mi piace, rimanendo dove amo vivere.

Conclusioni

L’azienda continua a crescere esponenzialmente. Abbiamo nuovi uffici fighissimi, tanti nuovi colleghi, e collaborazioni internazionali. Ho fatto un po’ di viaggi in Europa, cominciato a parlare inglese giornalmente, sono andato a molte conferenze, fatto esperienza in diversi settori della programmazione e ci sono state tantissime occasioni di divertirsi coi colleghi.

Lo dico in maniera diretta, così sono sicuro che arrivi esattamente il messaggio che ho in testa:

concentratevi sulle persone, non sulle tecnologie!

Potreste rimanere sorpresi.

Grazie per la lettura.

P.S.

Un’ ultima cosa… fidatevi… è comunque sempre meglio di Javascript 🤣! (Si fa per ridere, no flame 🔥 per favore! Mi piace molto lavorare anche in Javascript 😉)