Rivelazioni dagli anni settanta

(Questo post volevo scriverlo mesi fa, finalmente ho avuto il tempo di concluderlo)

Bazzicando l’ambiente del design object oriented, dell’ingegneria del software e dei metodi agili avevo spesso sentito citare The Mythical Man-Month, di Brooks, ma avevo sempre posticipato la sua lettura avendo scoperto che si tratta di un libro scritto trent’anni fa e che per lo più tratta di project management.

Come poteva un libro così datato avere qualcosa da dirmi che non fosse stato raffinato in questi trentanni in altri testi o che non fosse diventato spettacolosamente obsoleto?

Per chi non fosse del settore : per avere una sensazione della velocità con cui lavora l’obsolescenza nell’IT bisogna moltiplicare per 5 l’età di qualunque pezzo di informazione. Ad esempio, leggere oggi un saggio del 2005 che tratti di informatica è come per un medico leggere un saggio di dieci anni fa, del 1997. Un libro scritto nel 1995 invece dà tipicamente la stessa sensazione che avrebbe un ingegnere civile a leggere un libro di costruzione di viadotti di sessanta anni fa.

Davvero.

Sono persino conservativo in questa proporzione : se si pensa che molti testi di medicina, ingegneria civile, meccanica, aeronautica di sessanta anni fa hanno ancora un loro valore e utilità, mentre i libri di informatica di dodici anni fa che hanno ancora qualcosa da dire oggi si contano sulle dita di due mani, si potrebbe portare il moltiplicatore a 10.

Tornando a The Mythical Man-Month.

Questo libro ha trent’anni, quindi per altri settori sarebbe equivalente a un libro di 150 o anche 300 anni fa. Insomma, come se un chimico trovasse che la termodinamica di Sadi Carnot contenga per lui dei concetti innovativi.

Eppure questo libro di un’era passata asserisce concetti pertinenti la gestione dei progetti software complessi che, ad oggi, sono in buona parte ignorati.

Non voglio dire che il libro non abbia avuto audience. Al contrario, la sua fama è inequivocabile, ma questa fama evidentemente non ha influenzato proporzionalmente l’industria.

Questo libro è esistito ed è stato letto durante tutta la mania costruzionistica e predittivistica degli ultimi decenni, eppure frasi come “aggiungere forza lavoro a un progetto software in ritardo ne aumenta ulteriormente il ritardo” o capitoli come “il team chirurgico” che descrive come la massima priorità in un progetto software sia mantenere la coerenza concettuale del sistema sono stati largamente ignorati durante l’affondamento reiterato di progetto dopo progetto per cause perfettamente conosciute e continuando a spingere su processi che ignorano, se non acuiscono, queste ultime.
Addirittura la modularità (e quindi il disaccoppiamento) è stata presa a bandiera dell’approccio predittivo, mentre nel libro essa è strumentale alla possibilità di testare e far funzionare il sistema il prima possibile. La dichiarazione seminale del libro “It is a very humbling experience to make a multi-million dollar mistake” pone le basi per la successiva discussione dell’importanza di formare e coltivare le capacità di design dei propri tecnici, eppure questo è stato ignorato di fronte alle campane della sostituibilità delle persone.

L’attualità del libro è solo uno dei suoi meriti. Non solo è attuale, è anche estremamente netto. Brooks aveva le idee molto chiare e il dono di scriverle con eccezionale limpidezza. Il libro è ricolmo di frasi eleganti, forti e ben incapsulate, rendendole memorabili.

In fine queste frasi memorabili sono anche profetiche: descrivono con infinita chiarezza dolorosi errori di management dal costo esorbitante già sperimentati, ma che sarebbero stati ripetuti negli anni successivi e continuano, inesorabili, a essere ripetuti oggi.

Non posso nascondere un profondo fastidio riflettendo su questo libro. La mia esclamazione più frequente è stata : “Ma allora ve l’avevano detto! Lo sapevate!”.

Eppure ancora oggi si vedono gantt calcolati e aggiornati usando la proporzionalità inversa sul numero degli sviluppatori coinvolti, sottostimando il valore e il costo esplosivo della comunicazione all’interno di un progetto (cosa che è ancor oggi difficile da far accettare!).

Nella mia edizione è stato incluso un altro saggio di Brooks, più tardo di quelli che componevano l’originale MMM, ma altrettanto magistrale. “No Silver Bullet” prosegue infallibilmente la tradizione dei suoi predecessori nello sfatare i facili entusiasmi dell’industrializzazione del processo di sviluppo del software sulla base di un’intelligente distinzione nelle complessità che si affrontano nel mestiere : la complessità può nascere da cause essenziali e da cause incidentali.

Brooks spiega come, nella creazione di un sistema, si affronti una complessità incidentale, generata dagli “accidenti” della pratica, come ad esempio l’espressività (limitata) del linguaggio di programmazione, il ritardo con cui si ottiene il feedback del proprio lavoro o l’ambiguità dei messaggi di errore imprevisti. Allo stesso tempo si affronta una complessità essenziale, causata quindi dalla complessità intrinseca del problema da risolvere, insomma, da quelle che oggi chiameremmo business rules, ma non solo, la complessità essenziale nasce anche dalla varietà delle visualizzazioni richieste, dall’intrecciarsi delle politiche di persistenza dei dati dettate dal business, insomma, tutto ciò che, a prescindere dalla tecnica applicata alla soluzione, rende multisfaccettato il problema.

La conclusione di Brooks è elegante, come il resto del suo pensiero : pur ammettendo che la complessità essenziale sia tanto piccola da essere solo un decimo della complessità incidentale non vi sono all’orizzonte soluzioni che portino alla riduzione della prima, ma esclusivamente tecniche di gestione di singoli aspetti della seconda. Se anche tutte queste tecniche avessero avuto pieno effetto si sarebbe ottenuto un aumento di produttività di un fattore dieci e non oltre, di gran lunga inferiore a quanto era comune promettere ai tempi, perchè la complessità essenziale dei problemi fronteggiati da un progetto software non sarebbe stata intaccata da nessuna di esse.

Di fronte all’entusiasmo per l’esplosione delle capacità di calcolo dei computer è comprensibile che MMM, e più tardi “No Silver Bullet”, possano essere stati accusati di pessimismo, ma è imperdonabile che il primo e ancor più il secondo non siano diventati progressivamente il vangelo del management IT quando le loro previsioni si sono confermate perfettamente lucide e realistiche, piuttosto che pessimistiche.

Djikstra l’aveva detto in modo forse criptico quando aveva affermato che al crescere della potenza dei calcolatori il “problema” del software sarebbe esploso di pari passo, ma leggendo la prosa di Brooks non ci può essere giustificazione, la nettezza del suo pensiero rende la natura della sfida inequivocabile.

Equivocare ancora un messaggio così chiaro e continuare a promettere e ad accettare promesse di spettacolari incrementi di produttività tramite l’industrializzazione della programmazione, il più astratto degli sforzi progettuali della moderna tecnologia, non può più essere addotto a un’incomprensione avvenuta in buona fede : qualcuno, molti in verità, si sono tappati gli occhi e le orecchie per molto tempo e non hanno ancora smesso.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s