Dalla cultura hacker al mondo enterprise: 10 "regole" da sapere!
Un condensato di saggezza, tra il serio e il faceto
Original in Italian; automatic translation into English available here.
Intro
Qualche giorno fa, mi sono imbattuto in una collezione di perle di saggezza riportate come hacker laws… e mi sono sembrate subito un ottimo modo per iniziare il 2024 di questo blog!
Per chiarire, non c’è molto che abbia a che vedere direttamente con il mondo della sicurezza informatica. Ma del resto, il concetto di hacking in origine ha un’accezione diversa da quella che gli attribuiamo abitualmente: è il volersi sporcare le mani per capire fino in fondo una qualsiasi cosa, che sia un software, un prodotto, ma anche un aspetto della vita quotidiana. Per poi poterlo sfruttare al meglio, e non necessariamente in maniera illecita!
L’autore ha raccolto quasi 60 tra leggi, princìpi e massime: il fatto stesso che abbia scelto di pubblicarli su Github fa capire il suo background altamente nerd! Ma nonostante il target originario sia probabilmente il mondo tech (nel senso più ampio possibile), faccio fatica a pensare a qualcuno che non possa trovare interessanti almeno una parte di queste perle.
Un piccolo spoiler: di primo acchito, ne ho riconosciute (solo) una decina… ma poi ne ho scoperte tante altre di cui semplicemente non conoscevo il nome ufficiale.
Ciononostante, quasi metà sono state per me delle novità! E ho pensato di commentarne 10, così divise:
3 regole a me nuove;
altre 7 che già conoscevo… ma talmente geniali da meritare di essere ulteriormente diffuse!
Le 3 novità
Per il sollievo dei lettori meno tech, glisserò sull’efficientamento dei task di programmazione parallelizzabili e sulla teoria delle reti di calcolatori. Mi focalizzerò su qualche principio che trovo utile all’interno di qualsiasi azienda e che ritengo applicabile anche al di fuori di campi specifici.
Il Rasoio di Hanlon
Mai attribuire alla malafede quello che è adeguatamente spiegato dalla stupidità
Me ne sono reso conto più volte negli ultimi anni: che sia sul lavoro o altrove, quando vedo stranezze, errori marchiani e comportamenti inspiegabili, tendo ormai a considerare la malafede come ultima ipotesi. Ignoranza, incompetenza, superficialità e affini vengono ampiamente prima e spiegano tutto… o quasi.
Legge di Gall
Un sistema complesso che funziona è sempre l’evoluzione di un sistema semplice che funziona. Un sistema complesso progettato da zero non funziona mai, senza eccezione. Bisogna ripartire da un sistema semplice e funzionante.
Il concetto di agilità ed in particolare di MVP1 è esattamente legato a questa legge. Da citare tassativamente all’inizio di qualsiasi progetto pluriennale gestito in modalità waterfall e destinato al fallimento.
Legge di Cunningham
Il miglior modo per avere una risposta su internet, non è fare una domanda. È postare la risposta sbagliata.
Questa massima non vale solo su internet! Si applica brillantemente in molte interazioni aziendali, specie con quei curiosi individui appartenenti alla categoria degli ingegneri2.
Il modo migliore per attirare la loro attenzione non è porre una domanda (che spesso verrà percepita come superficiale e non meritevole di risposta): è sostenere una tesi che non condividono, finendo facilmente col triggerarli e ottenere quindi tutta l’attenzione e le informazioni richieste!
I 7 must… old but gold!
La lista dei princìpi che penso siano da conoscere va ben oltre questi 7, ma ho provato a fare un mix tra più o meno noti… e più o meno seri!
La legge di conservazione della complessità
In ogni sistema o processo, c’è un minimo livello di complessità che non può essere ridotto
Un bell’esempio che ho letto è l’operazione di preparare il caffé. Con una moka, richiede diversi passaggi: riempire la caldaia di acqua senza esagerare, inserire il filtro a imbuto, riempirlo di caffé, avvitare, mettere sulla fiamma, poi aspettare, spegnere, versare e smontare la moka.
Con una macchinetta a capsule, richiede di inserire la capsula e schiacciare un bottone.
Ma la complessità è sparita? No: l’attività è stata più semplice per l’essere umano, ma la complessità è andata nella macchinetta a capsule che è sicuramente più complessa di una moka!
L’effetto di Dunning-Kruger
L'ignoranza genera arroganza mentre la competenza genera dubbio e cautela
Le formulazioni dell’effetto Dunning-Kruger sono infinite, ma il grafico sopra sarà familiare a molti: è facile sopravvalutare la propria competenza su un argomento quando si sa veramente poco… così poco da non essere in grado di “sapere di non sapere”.
Legge di Hyrum
Con un numero sufficiente di utenti di un servizio, non importa cosa si promette nel contratto: ci sarà sempre qualcuno che si affida ad un comportamento esistente del sistema (anche se non previsto)
La formulazione originaria di questa legge è legata alle API, le interfacce attraverso cui un software espone servizi, funzionalità e dati. Ma in realtà si applica a chiunque metta a disposizione un qualche tipo di servizio o prodotto general purpose.
Più un servizio ha utenti e successo, più verrà usato anche in maniera del tutto imprevista… e tanto più aumentano le persone che dipendono da quel servizio, tanto più bisogna stare attenti a modificarlo. Nel mondo IT, direi: attenti ai breaking changes anche più innocui!
Ci sono due esempi che adoro. Il primo è relativo al mondo dei pagamenti digitali. Chi è interessato al settore, potrebbe conoscere una vicenda avvenuta in India qualche anno fa: per oltre un giorno, gli utenti di un circuito di pagamento indiano sono stati in grado di ordinare cibo gratis tramite Uber Eats! E tutto per una leggerezza nell’aggiornamento di un API e una serie di assunzioni implicite tra circuito e Uber, come spiegato splendidamente da Gergely Orosz
L’altro esempio è una classica vignetta di XKCD, destinata escludivamente a nerd/geek.
Peter principle
In una gerarchia, ogni dipendente tende a salire di grado fino al proprio livello di incompetenza
Classica satira sulla meritocrazia e le sue distorsioni.
Se si è bravi nel proprio lavoro, si viene promossi (o così dovrebbe essere). Fino a quando non si raggiunge un livello in cui non si è più in grado di fare per bene il proprio lavoro… e lì si rimane, a diffondere la propria inadeguatezza!3
Legge di Goodhart
Quando una misura diventa un obiettivo, cessa di essere una buona misura
Sono un grande fan di questa legge, che potrei riformulare così: attenzione a non trasformare le logiche data-driven in un boomerang!
Non è un caso che un intero capitolo di Data Culture sia dedicato alla misura delle performance e dell’efficacia nell’uso dei dati: è facilissimo, con colpa o con dolo, definire dei KPI manipolabili e hackerabili ben oltre l’immaginabile, specie se questi sono legati a valutazioni e/o incentivi.
Rasoio di Occam
È inutile fare con più ciò che si può fare con meno
Detta anche principio di parsimonia, questa massima è alla base di tante soluzioni di successo. Come dice qualcuno: è facile complicare, è difficile semplificare.
Mi piace molto un’intervista ad Elon Musk (di cui sono ben lontano dall’essere un sostenitore) in cui ha dichiarato:
The best part is no part. The best process is no process. It weighs nothing. Costs nothing. Can't go wrong.
Non so se si riferisse all’efficienza organizzativa (ridurre meeting e processi inutili), oppure all’efficienza tecnica (ridurre i sensori sulle sue Tesla, favorendo un approccio vision-only anziché vision and radar), ma in ogni caso quella di Musk è proprio una formulazione nello spirito di Occam… ma 700 anni dopo.
Two pizza rule
Due pizze (americane) devono bastare a saziare un team di progetto o le persone in un meeting
Concludo con un classico attribuito a Jeff Bezos.
Partiamo dal fatto che si suppone che una pizza americana sia abbastanza per 5 persone… ne consegue che non devono esserci meeting o team di progetto superiori alle 10 persone.
Condivido ampiamente questo approccio! C’è spazio per incontri più estesi per condivisione, community e altro, ma quando si parla di incontri operativi legati allo sviluppo di un progetto, già 10 persone sono decisamente troppe. Il rischio di gruppi più estesi va dall’inevitabile lentezza fino al bias di autorità, secondo cui aumenta il rischio di veder prevalere il famigerato HiPPO (highest-paid person opinion).
Conclusioni
Che si vogliano chiamare hacker laws, o magari geek oppure nerd laws, ho trovato veramente tanti spunti validi nel compendio di Dave Kerr da cui sono partito per questo articolo.
Sta a ciascuno di giudicare quali sono più o meno applicabili alla propria realtà, e magari capire come possano essere un punto di partenza per correggere il tiro sulle piccole e grandi difficoltà che ci troviamo ad affrontare tutti i giorni!
Inteso come Minimum Viable Product… non come il Most Valuable Player dell’NBA!
Categoria che mi permetto di prendere in giro… dato che ci appartengo e ne condivido a mio modo difetti e stranezze.
Particolarmente valido in quei paesi, come l’Italia, dove la tutela del posto di lavoro è portata all’estremo. Un po’ meno nel mondo anglosassone.
Fantastica questa puntata di newsletter, ci ricorda sempre che semplificare è meglio che complicarsi la vita!!!