La legge di Hofstadter

Risultati immagini per eterna ghirlanda brillanteUn bel po’ di anni fa ormai, mi sono imbattuto nella lettura di un saggio che mi ha letteralmente folgorato. Si trattava di: “Gödel, Escher, Bach: un’eterna ghirlanda brillante“, di  Douglas Hofstadter. Il saggio è un viaggio tra le opere di logica di Godel, i quadri visionari di Escher e la musica di Bach: apparentemente sembrano cose molto lontane fra di loro ma in realtà dietro c’è un processo logico-mentale che accomuna le tre opere. Ad una seconda lettura, il saggio è ancora molto più articolato perché si rivela essere una riflessione sui processi mentali alla base del pensiero e sulle regole formali relative.

Senza volersi addentrare troppo nei contenuti del saggio, al suo interno viene enunciata una legge che ha segnato (e segnerà sempre) le metodologie di sviluppo del software, ed è legata alla percezione umana dei fenomeni complessi e del tempo

La legge enuncia:

It always takes longer than you expect, even when you take into account Hofstadter’s Law

ovvero

Per fare una cosa ci vuole sempre più tempo di quanto si pensi, anche tenendo conto della Legge di Hofstadter

Hofstadter arriva a postulare questa legge ragionando sugli errori delle previsioni  che sono state fatte nel tempo sul progresso tecnologico, in particolare analizzando le previsioni che già alla fine degli anni ’70 prevedevano che un computer avrebbe battuto l’uomo nel gioco degli scacchi. In realtà, altro che anni 70, ce sono voluti altri 30!!!!

Risultati immagini per escher complexityLa legge postula l’impossibilità dell’uomo di riuscire a quantificare il tempo necessario per svolgere una attività specie se complessa, anche quando si è coscienti di questa difficoltà e si prova a tenerne conto. E da cosa nasce questa difficoltà secondo Hofstadter? Nasce dalla percezione dei fenomeni complessi da parte del nostro cervello: non siamo fatti per percepire in maniera piena e cosciente la complessità e qualunque nostro tentativo di provare a farlo ci porta a sottostimare la realtà (come in un quadro di Escher).

Stante a questa legge, siamo condannati ad essere sempre in ritardo: se intraprendiamo un lungo viaggio, una grossa opera pubblica, un grosso progetto, la legge di Hofstadter è sempre in agguato e qualunque pianificazione che verrà data sarà sbagliata. Anzi, secondo questa legge, le cose stanno ancora peggio: se proviamo a ipotizzare di prenderci del tempo in più (una “contingency”) o di sovrastimare, perché sappiamo già come andrà a finire, succederà esattamente che anche la sovrastima sarà sbagliata.

Non c’è via di scampo!!! Più  complessa è l’attività, maggiore è l’ineluttabilità di questa legge.

L’impatto di questa cosa sui progetti software la viviamo di fatto tutti i giorni: a chi vive di sviluppo software, fornire stime ed essere in ritardo e correre per farcela è una consuetudine quotidiana.

I metodi classici dell’organizzazione, di derivazione tipicamente militare, consigliano la classica tecnica del dividi-et-impera: dividi il progetto in tante micro-attività, stima le micro-attività e poi calcoli il totale. Questo modo di procedere si applica bene ai sistemi complicati, ma, come descritto anche qui, parlando del Cynefin framework, nei sistemi complessi il totale non è la somma delle parti. Occorre procedere in maniera diversa per riuscire ad avere una controllo di un progetto.

Siamo di fronte ad un’altra delle leggi che sono alla base della nascita delle Metodologie Agili; in Scrum ma anche nelle pratiche XP dell’Extreme Programming, il processo di stima è fortemente debitore di Hofstadter.

  • basta stime in giorni uomo o mesi/uomo basati sulla suddivisione in micro attività
  • basta Gantt che provano a dettagliare un piano e i tempi anche delle singole micro-attività
  • basta tentativi di avere stime precise e dettagliate sin dalle prime fasi del progetto

E’ tutto inutile: nei sistemi complessi non siamo in grado di stimare con esattezza nulla, anche prendendoci una apparente sufficiente contingency. Ma allora come si fa?

Inutile perdere tanto tempo nel cercare di stimare l’impossibile all’inizio. L’unica cosa di cui possiamo essere sicuri è la nostra esperienza, e quindi meglio macro-stimare un progetto sulla base dell’esperienza precedente, per confronto con altri casi; certo, potrebbe venire un numero elevato, maledettamente elevato, ma spesso è quello reale; e comunque non saremo in grado di produrre una stima migliore.

Risultati immagini per scrum estimation

E a seguire occorre andare verso un processo continuo di refinement della stima, che step dopo step, man mano che migliora la comprensione del progetto e della realtà, mira a raggiungere una stima più precisa.

E’ il concetto del cono di incertezza: all’inizio di un progetto potremmo avere margini di errore molto elevati, che si riducono solo andando avanti nel progetto

Risultati immagini per estimation cone uncertainty scrum

Ed è quello che succede in metodologie come Scrum, dove la stima si aggiorna ad ogni sprint, e il feedback continuo, ogni 15 giorni, permette al team di prendere decisioni, fare tuning, affinare la stima, partendo da un primo dimensionamento del progetto a T-shirt size, spesso ottenuto tramite estimation-by-affinity

Quello che le metodologie agili ci insegnano nel software è che il problema non è aggirare la leggi di Hofstadter: è una legge e come tale vale sempre; ogni tentativo di aggirarla produce effetti non accettabili, come la legge stessa prescrive nella sua seconda parte. Quello che dobbiamo imparare è come predisporci per essere maggiormente adattivi; non è importante seguire un piano minuziosamente, ma è fondamentale la capacità di riadattarsi rapidamente e modificare il piano.

Quello della stima resta comuqnue comunque molto difficile, spesso scolpito sulla pelle di tanti developer.

Le altre Leggi alla base dello Sviluppo Software

Questa voce è stata pubblicata in Leggi Sviluppo Software e contrassegnata con . Contrassegna il permalink.

Rispondi