Summary: they often say that software engineering is about transitioning from craftsmanship to craft + science. The flaw in this reasoning is that practice in software development is not yet at the craftsmanship stage. (By a similar reasoning we see that even computing science is not really science, but is at a pre-science stage.)
Employers … complain that they do not know what a graduate of either a CS program or a traditional engineering program can be expected to know about software development.
— David Parnas
Si sente spesso dire che l’idea di software engineering consiste nel passare da uno stadio artigianale, caratterizzato da modi di lavorare provati dall’esperienza, a uno stadio scientifico, in cui la scienza ci permette di andare oltre gli schemi tramandati dalla tradizione per scoprirne di nuovi.
Sono perfettamente d’accordo con questa immagine di come la scienza, combinata a un sapere empirico artigianale, conduce all’ingegneria. Nel caso dello sviluppo software, però, c’è un piccolo problema. Noi non siamo ancora a uno stadio artigianale. Siamo a uno stadio pre-artigianale.
E’ facile dimostrare questa mia asserzione. Si prendano due praticanti qualsiasi dello sviluppo software (e intendo persone che siano realmente in grado, personalmente, di realizzare software; non astratti architetti che promulgano documenti che vengono puntalmente ignorati da chi fa il lavoro veramente.) Si prendano, dicevo, due praticanti a caso. Non saranno d’accordo su praticamente nulla. In questo mestiere non ci sono metodi universalmente riconosciuti come validi. Dalla maniera di scrivere i commenti fino alla scelta degli strumenti, i nostri due ipotetici praticanti saranno in totale dissenso su quasi tutto.
E questo resta vero anche se scegliamo due praticanti a caso all’interno della stessa tribù; ad esempio due sviluppatori Java o due sviluppatori C#. Saranno d’accordo sulla scelta del linguaggio di programmazione, ma cominceranno a discutere sulla maniera di accedere al database, sulla scelta dei framework e, indubbiamente, sulla maniera di scrivere i commenti.
Che cosa caratterizza l’artigianato? La cosa che maggiormente lo caratterizza è l’apprendistato: il giovane apprendista acquisisce il suo know-how direttamente da un artigiano di provata capacità. In questo modo si formano scuole che hanno un loro modo di fare le cose. Ci saranno senz’altro grosse differenze fra il modo di lavorare delle scuole, così come l’architettura tradizionale ha un suo diverso carattere in tutte le parti del mondo; ma se prendiamo due artigiani a caso nella stessa scuola avranno un insieme di modi di lavorare condivisi.
Nel mondo dello sviluppo software invece… Sappiamo benissimo che non è così. Ognuno impara a fare le cose essenzialmente da solo. All’università si lavora da soli, o magari in gruppo con altri studenti che però sono anche loro inesperti. Al lavoro ci si aspetta che ognuno lavori in maniera indipendente. Non capita mai che a un progammatore junior si affianchi uno senior che lo segua e spenda del tempo per trasmettergli il know-how. Lo so bene, per le reazioni scioccate che osservo quando propongo di fare pair programming: il capo progetto obietta “ma così spendo il doppio per fare le stesse cose,” senza capire che così sia lo junior che il senior progrediscono rapidamente e riescono a produrre un valore che è ben maggiore della somma di quello che potrebbero realizzare lavorando sempre da soli.
Immaginate una cosa simile in una società preindustriale, se ogni muratore imparasse da solo, senza guida di un esperto, a costruire i muri. Salterebbe fuori che 99% dei muri sarebbero storti e sbilenchi, e fragili. Solo quell’1% di persone baciate dalla fortuna di un talento naturale riuscirebbero a costruire un bel muro dritto e robusto.
Noti qualche somiglianza con il mondo dello sviluppo software oggi? Hai provato a osservare l’orrendo casino che passa per codice scritto dai programmatori professionisti?
Se hai seguito il mio ragionamento, dovresti trovare facile capire, a questo punto, il grande successo di Extreme Programming e degli altri metodi agili. Sono un tentativo di uscire dalla fase pre-artigianale per raccogliere un corpus di metodi provati dall’esperienza. Kent Beck ha detto che XP non è altro che una codifica organica di cose che i migliori programmatori hanno sempre fatto. Sono molto contento di quello che vedo nella scena XP, perché i practitioner hanno una comprensione condivisa di una serie di cose che sono state provate efficaci dall’esperienza. Non solo: c’è una condivisione di valori, che permettono di lavorare insieme, al di là delle preferenze personali in fatto di linguaggi di programmazione.
Posso concludere il mio ragionamento su una nota polemica? Certo che sì, questo è il mio blog. Estendiamo il mio esperimento concettuale di prima al mondo della computing science o informatica. Prendiamo due computer scientist a caso: non saranno d’accordo su praticamente nulla. Con ogni probabilità le rispettive tribù parleranno linguaggi così diversi che non saranno nemmeno in grado di spiegarsi l’un l’altro in cosa consiste il loro lavoro. Il mondo della ricerca informatica è finemente suddiviso in miriadi di sottotribù che si occupano magari delle stesse cose, ma usano metodi e linguaggi completamente diversi. Gli articoli pubblicati sono mediamente illeggibili dai non-membri della minuscola tribù dell’autore. Un esempio su tutti: lo studio della concorrenza. Dalle cosiddette “teorie dei processi” di Milner/Hoare alla teoria dei linguaggi di programmazione alla teoria delle basi di dati, non c’è verso di avere non dico una teoria, ma nemmeno un linguaggio unificato su problemi che alla fine sono comuni. Con il risultato che fra la ricerca e la pratica in informatica c’è un baratro di incomunicabilità, che tende ad allargarsi.
[Grazie a Federico per la discussione che ha fatto emergere questi pensieri]