C’è un progetto open source che si chiama Hacker Laws, curato dallo sviluppatore Dave Kerr, che raccoglie in un unico posto decine di “leggi”, teorie, principi e pattern citati continuamente nel mondo dello sviluppo software. È il genere di repository che chi lavora nella tecnologia si passa nei gruppi di lavoro, un po’ come un vocabolario condiviso.
La cosa interessante è che quasi nessuna di queste “leggi” parla davvero di codice. Parlano di come si comportano le persone, i gruppi di lavoro, i progetti e le organizzazioni — solo che sono nate in ambito informatico. Per questo vale la pena conoscerle anche se non hai mai scritto una riga di codice in vita tua: raccontano dinamiche che riconoscerai in ufficio, in un progetto editoriale, in un gruppo di volontariato o in una chat di famiglia.
Ecco una selezione tradotta e spiegata in italiano, con parole semplici. Per l’elenco completo (sono più di quaranta) trovi il repository originale in fondo all’articolo.
Il principio di Pareto (la regola dell’80/20)
L’osservazione, nata studiando la distribuzione della ricchezza in Italia a inizio Novecento, dice che spesso una piccola parte delle cause produce la maggior parte degli effetti: l’80% dei risultati arriva dal 20% degli sforzi. Nello sviluppo software si traduce così: la maggior parte dei bug si concentra in una piccola parte del codice, o la maggior parte del valore di un prodotto sta in poche funzionalità. Fuori dal software, è la stessa logica per cui pochi clienti generano gran parte del fatturato, o poche attività della giornata producono quasi tutti i risultati importanti.
L’effetto Dunning-Kruger
Probabilmente l’hai già sentito nominare, spesso a sproposito. È l’osservazione — confermata da studi di psicologia cognitiva — per cui chi ha competenze molto limitate in un campo tende a sovrastimare le proprie capacità, semplicemente perché non ha gli strumenti per accorgersi di quanto non sa. Con l’esperienza, la fiducia in sé stessi spesso cala prima di risalire: più impari, più ti accorgi di quanto c’è ancora da imparare.
La legge di Conway
Un’osservazione che sembra un gioco di parole ma è tremendamente concreta: la struttura di un sistema finisce per rispecchiare la struttura di comunicazione dell’organizzazione che lo costruisce. Se in azienda ci sono tre team che non si parlano tra loro, il prodotto finale tenderà ad avere tre “pezzi” scollegati, indipendentemente da come era stato progettato sulla carta. Vale per il software, ma vale anche per un giornale, un evento organizzato da più uffici o un sito web costruito da agenzie diverse che non si coordinano.
La legge di Brooks
“Aggiungere manodopera a un progetto già in ritardo lo fa ritardare ancora di più.” Nasce dall’osservazione che le nuove persone che arrivano su un progetto hanno bisogno di tempo per essere formate, e nel frattempo rallentano chi il progetto lo conosce già. È il motivo per cui “buttare gente sul problema” all’ultimo momento, in qualsiasi tipo di progetto, spesso peggiora le cose invece di risolverle.
La legge di Parkinson
“Il lavoro si espande fino a riempire tutto il tempo disponibile per completarlo.” Se hai una settimana per un compito che ne richiederebbe due giorni, in qualche modo finirai per impiegarci comunque quasi una settimana. È probabilmente la legge più universalmente riconoscibile della lista, e vale tanto per un progetto software quanto per una tesi di laurea.
La legge di Murphy
“Se qualcosa può andare storto, andrà storto.” Non è una legge fisica né una vera teoria scientifica, ma un promemoria utile: nella progettazione di qualunque sistema — informatico o no — conviene prevedere che le cose vadano storte, invece di sperare che non succeda.
Il rasoio di Occam
Un principio antico (nasce nel Trecento, con il frate francescano Guglielmo di Occam) riadattato al lavoro tecnico: a parità di risultato, la spiegazione o la soluzione più semplice è di solito quella giusta. Nello sviluppo si traduce in “non costruire un sistema complicato se ne basta uno semplice”, ma è un principio che vale per qualsiasi tipo di problem solving.
La legge di Cunningham
“Il modo migliore per ottenere la risposta giusta su internet non è fare una domanda, ma pubblicare la risposta sbagliata.” Chi lavora online la riconosce benissimo: un post che afferma qualcosa in modo sbagliato genera molte più correzioni (e quindi risposte) di una domanda onesta. È una chiave di lettura utile anche per capire certe dinamiche dei social media.
La legge di Hofstadter
“Ci vuole sempre più tempo di quanto previsto, anche tenendo conto della legge di Hofstadter.” È un paradosso quasi comico che però descrive un’esperienza condivisa da chiunque abbia stimato la durata di un progetto: la nostra stima iniziale è quasi sempre ottimistica, e lo resta anche quando proviamo a correggerla per essere più prudenti.
Input-Process-Output (IPO)
Questo è forse il modello più semplice — e più utile fuori dal software — di tutto l’elenco, tanto che vale la pena dedicargli qualche riga in più. L’idea è che qualsiasi sistema può essere descritto in tre fasi: riceve qualcosa (Input), lo elabora in qualche modo (Process) e produce un risultato (Output).
Detta così sembra ovvia, ma è uno strumento mentale potente perché puoi applicarlo a qualunque cosa, non solo a un programma: una ricetta di cucina (ingredienti → cottura → piatto), una riunione di lavoro (informazioni portate dai partecipanti → discussione → decisione presa), persino un articolo come questo (una fonte da capire → un lavoro di sintesi e scrittura → un testo che il lettore può usare). Quando qualcosa non funziona, il modello IPO è un modo semplice per capire dove si è rotto il processo: manca un input, il processo è sbagliato, o l’output non è quello che serviva davvero.
Perché conoscerle, anche se non scrivi codice
Queste “leggi” non sono verità scientifiche: sono osservazioni ricorrenti, spesso ironiche, nate da persone che lavorano in team, gestiscono progetti e devono spiegare cose complicate ad altre persone — lo stesso lavoro che fa chiunque si occupi di comunicazione, organizzazione o contenuti. Conoscerle dà un vocabolario comune per riconoscere pattern che altrimenti si notano solo “a pelle”, senza riuscire a nominarli.
Dove approfondire
Il progetto Hacker Laws è open source, gratuito, e in costante aggiornamento grazie ai contributi della community:
- 🔗 Repository originale su GitHub: github.com/dwmkerr/hacker-laws
- 🌍 Versione sito web: hacker-laws.com
- 🇮🇹 È disponibile anche una traduzione italiana completa del progetto, curata dalla community: translations/it-IT.md
- 📖 Esiste anche un eBook PDF scaricabile gratuitamente con l’intera raccolta
Se l’articolo ti ha incuriosito, il repository ne contiene più del doppio rispetto a quelle citate qui — tra cui il teorema CAP, la legge di Moore, lo YAGNI e i principi SOLID, più tecnici ma comunque leggibili anche senza background da sviluppatore.