I problemi nel mondo IT non sono casuali: seguono gli stessi principi

Dopo qualche anno nel mondo del lavoro, soprattutto nell’IT, se sei una persona curiosa e attenta a ciò che ti circonda, inizi a notare una cosa strana: problemi diversi, aziende diverse… ma dinamiche sempre uguali.

Non è un caso.

Da appassionato di pattern ricorrenti, ho sempre cercato di astrarre queste situazioni, provando nel tempo a mapparle su altri contesti. La cosa sorprendente è che il mapping risultava perfetto: situazioni analoghe, attori diversi, stesso epilogo.

Col tempo, spinto dalla curiosità e dalla convinzione di non essere l’unico a osservare queste dinamiche, ho iniziato a studiare e documentarmi, cercando di capire se altri si fossero trovati in situazioni simili, o semplicemente le avessero osservate. La cosa interessante è che, approfondendo, ho scoperto un intero mondo di “leggi non scritte” che descrivono perfettamente questi fenomeni e provano a spiegare perché accadono.

Così, per puro divertimento, ho pensato di condividerle in questo articolo. Magari può risultare interessante per qualche altra persona curiosa, che prova ad astrarre un pattern comportamentale da una situazione vissuta.

Ho quindi raccolto una serie di “leggi non scritte” che cercano di spiegare perché certi eventi si verificano: alcune riguardano il codice, altre le persone… e quasi sempre il problema sono le seconde.

Per dare un minimo di struttura, ho provato a raggrupparle in quattro categorie che, almeno per me, hanno senso:

• Leggi del codice (o comunque leggi tecniche)
• Leggi delle astrazioni e della complessità
• Leggi delle persone
• Leggi del caos

Di seguito provo a raccoglierne alcune, quelle che ho vissuto più direttamente (consapevole che ce ne siano molte altre).

Leggi del codice

Linus’s Law (≥ 1997)

“Con abbastanza occhi, i bug diventano facili da individuare.”

📖 Fonte: The Cathedral and the Bazaar – Eric S. Raymond
http://www.catb.org/~esr/writings/cathedral-bazaar/

È una di quelle frasi che, all’inizio, sembrano quasi banali… finché non inizi a viverle davvero.

In teoria: più persone guardano il codice → più probabilità di trovare problemi.

In pratica: il bug su cui stai impazzendo da giorni… viene trovato in 30 secondi da qualcun altro.

Quante volte succede?
Ore davanti allo stesso blocco di codice. Debug, log, tentativi, ipotesi.

Poi arriva qualcuno, guarda lo schermo e dice:
“ma qui… manca un controllo.”

Fine.

Ed è lì che realizzi quanto sia paradossale: era davanti a te tutto il tempo, ma non lo vedevi.

E capisci che il problema non era la complessità…era semplicemente il numero di occhi.

Law of Leaky Abstractions (2002)

“Ogni astrazione non banale, prima o poi, perde dettagli sottostanti.”

📖 Fonte: Joel Spolsky
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

Questa è una delle leggi più vere in assoluto. Una di quelle con cui, prima o poi, tutti si scontrano.

Soprattutto quando usi framework, librerie, PaaS.

Le astrazioni esistono per semplificare: ti promettono che non devi sapere cosa c’è sotto.
E funziona. Finché funziona.

Poi qualcosa cambia.

• le performance calano
• qualcosa si rompe
• il comportamento non è quello atteso
• provi a forzare il framework con logiche che sai essere possibili… ma non sono esposte

E a quel punto non hai scelta: devi scavare sotto.

Ed è lì che arriva la vera realizzazione:

stavi usando qualcosa che non avevi mai davvero capito…o che non avevi capito fino in fondo.

Le astrazioni non eliminano la complessità,  la nascondono… fino a quando non torna a cercarti.

Hyrum’s Law (≥ 2014)

“Con abbastanza utenti, ogni comportamento osservabile diventa una dipendenza.”

📖 Fonte: https://www.hyrumslaw.com/

Questa è sottile… ma devastante.

Puoi documentare un’API quanto vuoi. Puoi specificare cosa è supportato e cosa non lo è.

Non importa.

Se un comportamento esiste — anche se non documentato — qualcuno lo userà.

E nel momento in cui proverai a cambiarlo… qualcosa si romperà.
Anche se, tecnicamente, non avrebbe mai dovuto funzionare così.

È qui che capisci una cosa fondamentale:

gli utenti non usano solo ciò che documenti, usano tutto ciò che osservano.

E quindi, in produzione, nulla è davvero “interno”, ogni dettaglio esposto… è una promessa, anche se non volevi farla.

Leggi delle astrazioni e della complessità

Se le prime spiegano il codice, queste spiegano perché il codice, col tempo, diventa ingestibile.

Hofstadter’s Law

“Ci vuole sempre più tempo del previsto, anche quando si tiene conto della legge di Hofstadter.”

📖 Fonte: Douglas Hofstadter, Gödel, Escher, Bach
🔗  Wikipedia – Hofstadter’s Law

All’inizio ci si illude di saper stimare. Poi capisci che stai semplicemente indovinando meglio.

Perché:

• non conosci tutte le variabili
• sottovaluti i dettagli
• sopravvaluti la linearità

E anche quando tieni conto del fatto che sbaglierai…sbagli comunque.

Forse il segreto è sbagliare il meno possibile, oppure prevedere una contingency in grado di assorbire l’eventuale discrepanza. 

Brooks’s Law

“Aggiungere persone a un progetto in ritardo lo ritarda ulteriormente.”

📖 Fonte: Frederick P. Brooks – The Mythical Man-Month
🔗Wikipedia – Brooks’s Law

Questa è controintuitiva finché non la vivi davvero. È stata una delle prime esperienze che ho fatto: cliente importante, progetto in forte ritardo, ore di extra-time che ormai non si contavano più, e un project manager che ogni settimana introduceva nuove persone nel team.

D’altronde, quando un progetto è in difficoltà, la reazione naturale è: “mettiamo più persone”.

Ma più persone significa:

• più comunicazione
• più allineamenti
• più contesto da trasferire

E chi già lavorava… cosa fa? Rallenta per allineare gli altri.

La situazione diventa frustrante: chi si porta addosso mesi di extra-time si ritrova a dover formare persone che hanno bisogno di tempo per apprendere, che hanno dubbi e che, inevitabilmente, non sono ancora operative.

Solo chi ha queste cicatrici sulla pelle lo sa:
l’emergenza si anticipa, le persone si formano prima che un progetto entri in criticità.

Purtroppo, solo chi ha vissuto certe situazioni dovrebbe poter gestire progetti o ricoprire ruoli di responsabilità.

Leggi delle persone

Questa è la parte che mi ha sempre più incuoriosito, qui ho davvero nel tempo visto le cose più strane ed dove penso che iniziano i problemi veri.

Perché il codice è complicato, ma è (o almeno dovrebbe essere) deterministico. Le persone, invece, lo sono molto di più.

Principio di Peter

“Le persone vengono promosse fino al loro livello di incompetenza.”

📖 Fonte: Laurence J. Peter – The Peter Principle
🔗 Wikipedia – Peter Principle

All’inizio sembra cinico, poi inizi a riconoscerlo.

Il miglior sviluppatore diventa team lead e, con il tempo, il team lead diventa manager.

E a un certo punto… non è più nel ruolo giusto. Viene allontanato da quello in cui eccelleva e spostato in uno in cui non porta più lo stesso valore aggiunto.

Cambia completamente la prospettiva: prima era il più esperto nella stanza, quello con più competenze; adesso diventa quello da formare. In un attimo si passa da senior a junior.

Perché, come spesso accade, il valore dipende dalla prospettiva con cui guardi le cose.

E per molti (non tutti, ovviamente) finisce lì: entrano in una sorta di limbo, in cui la crescita si ferma. Non perché non siano bravi, ma perché il ruolo è diverso.

Dilbert Principle

“Le aziende tendono a spostare le persone meno competenti nei ruoli manageriali.”

📖 Fonte: Scott Adams – The Dilbert Principle
🔗Wikipedia – Dilbert Principle

Qui il tono cambia.

Non è più un effetto collaterale: è quasi una strategia.
Chi crea problemi operativi viene allontanato dall’operatività… e spesso finisce a prendere decisioni.

Nei primi anni di esperienza osservavo questo fenomeno con stupore.
Ne parlavamo con i colleghi alla macchinetta del caffè, con frasi del tipo:

“Hai visto quello che ha creato un build break?
Ha completamente cannato quel design, ha portato quel progetto in ritardo… ed è stato promosso?

Adesso è responsabile tecnico del nuovo progetto?”

Poi, con il tempo, ti smalizi.
Perdi l’ingenuità e inizi a capire che quella promozione non è casuale: è una strategia.

Hai semplicemente spostato un problema a un altro livello… e ne sei uscito in modo elegante.

Grandi maestri.

Gervais Principle

“Non vince chi è competente. Vince chi capisce il gioco.”

📖 Fonte: Venkatesh Rao
https://www.ribbonfarm.com/the-gervais-principle/

Questa è probabilmente la più “scomoda”.

Non basta essere competenti: spesso fa la differenza capire come funzionano davvero le dinamiche dell’organizzazione.

Le aziende non sono sistemi meritocratici puri. Nella maggior parte dei casi somigliano molto più a sistemi sociali complessi.

E come in ogni sistema sociale, chi comprende le dinamiche di:

• relazioni
• percezione
• potere

ha un vantaggio reale.

Quante volte il tecnico molto competente resta bloccato in un ruolo, mentre chi sa muoversi meglio nel contesto cresce più velocemente?

Probabilmente più spesso di quanto vorremmo ammettere.

Leggi del caos

E infine, quelle che chiudono il cerchio, perché c’è sempre quel filo imprevedibile che lega qualunque cosa, perché anche quando tutto sembra perfetto…non lo è.

Legge di Murphy

“Se qualcosa può andare storto, lo farà.”

📖 Fonte: Murphy’s Law (attribuita a Edward A. Murphy Jr.)
🔗 Wikipedia – Murphy’s Law

Non è pessimismo. È statistica applicata alla realtà.

In IT significa:

• funziona in locale
• funziona in test
• si rompe in produzione   

Sempre nel momento peggiore, sempre con il cliente più critico.

Sempre di venerdì… o appena prima di una giornata (o di un periodo) di ferie che ti sei conquistato con fatica. 🙂

Hanlon’s Razor

“Non attribuire alla malizia ciò che è spiegabile con incompetenza.”

📖 Fonte: https://en.wikipedia.org/wiki/Hanlon%27s_razor

Questa è una consapevolezza quasi liberatoria.

Quante volte ci siamo trovati di fronte a problemi aberranti, a situazioni al limite dell’inverosimile? Problemi così evidenti da far pensare alla malafede di chi li ha prodotti.

Purtroppo, la realtà è un’altra.

Molti problemi:

• non sono sabotaggi
• non sono cattiveria 

sono semplicemente errori.
Sono semplicemente incompetenza di chi dovrebbe ricoprire un ruolo e non è in grado di farlo.

Non è una questione di malizia o volontà, ma solo ed esclusivamente di incompetenza.

E capirlo cambia completamente il modo in cui reagisci.

Considerazione finale

Ci sono così tanti principi e regole che, per elencarli tutti, bisognerebbe scrivere un libro.

Qui ho voluto raccogliere quelli con cui mi sono scontrato più spesso. Perché, dopo un po’, inizi a vedere queste leggi ovunque.

Progetti diversi.
Aziende diverse.
Persone diverse.

Stesse dinamiche.

E forse la vera skill non è evitarle — perché, in molti casi, sono inevitabili — ma riconoscerle prima degli altri.

Perché a quel punto non stai più reagendo ai problemi.

Stai anticipando i pattern.