Chiarezza attraverso la focalizzazione

Introduzione: L'illusione dell'inclusività attraverso la complessità

L'industria del software moderna predica l'inclusività come virtù. Tuttavia, nella pratica, ha costruito sistemi che richiedono un carico cognitivo sempre maggiore dai propri utenti---ingegneri, operatori e utenti finali alike. Ci viene detto che la “personalizzazione” e le “interfacce adattive” risolvano il problema delle diverse capacità degli utenti. Ma questo è un'illusione pericolosa. Il vero problema non è che gli utenti siano troppo diversi; è che i sistemi siano troppo complessi. Quando cerchiamo di adattare i messaggi a ogni possibile livello di comprensione, non diamo potere agli utenti---frammentiamo l'integrità del sistema. Scambiamo chiarezza per camuffamento, eleganza per entropia.

Questo documento sostiene che l'adattamento dei messaggi a capacità utente radicalmente diverse non è una soluzione---è un sintomo di fallimento sistemico. La vera via verso la chiarezza non sta nell'adattare il messaggio, ma nel progettare sistemi così matematicamente solidi, architetturalmente resistenti ed elegantemente minimi che non serva alcun adattamento. Un sistema che richiede messaggi diversi per un principiante e un esperto ha già fallito il suo dovere fondamentale: essere comprensibile da chiunque possieda una conoscenza sufficiente del dominio---e non richiedere più conoscenza di quanto strettamente necessario.

Scriviamo non per i tecnologi che inseguono la novità, ma per coloro che hanno visto il cimitero dei framework abbandonati, i cadaveri delle piattaforme sovra-progettate e la silenziosa disperazione degli ingegneri costretti a mantenere sistemi che nessuno comprende appieno. Scriviamo per i Ludditi---non come zelanti anti-tecnologia, ma come guardiani della ragione, della precisione e del valore duraturo.

Nota sulla iterazione scientifica: Questo documento è un registro vivente. Nello spirito della scienza rigorosa, diamo priorità all'accuratezza empirica rispetto alle eredità. Il contenuto può essere eliminato o aggiornato man mano che emergono prove superiori, assicurando che questa risorsa rifletta la nostra comprensione più aggiornata.

L'imperativo matematico: il codice deve essere dimostrabile

Sistemi formali come unica fondazione affidabile

Tutto il software, indipendentemente dal dominio di applicazione, è in ultima analisi un sistema formale. Opera secondo regole---logiche, sintattiche, semantiche---that devono essere coerenti e complete per evitare fallimenti catastrofici. I teoremi di incompletezza di Gödel non ci proibiscono di costruire sistemi affidabili; avvertono che i sistemi non dimostrabili non possono essere fidati. Un sistema il cui comportamento non può essere verificato formalmente non è semplicemente rischioso---è fondamentalmente insicuro.

Considera un'applicazione web che genera dinamicamente messaggi di errore in base al ruolo dell'utente, alla posizione o al comportamento precedente. Il messaggio “Si è verificato un errore interno” diventa “Il tuo account non ha i permessi per accedere a questa risorsa”, o peggio ancora, “Riprova più tardi---stiamo sistemando.” Questi non sono chiarimenti; sono oscuramenti. Ogni variazione introduce una nuova ramificazione nello spazio degli stati. Ogni ramificazione deve essere testata, mantenuta e verificata. Il numero di possibili permutazioni dei messaggi cresce in modo combinatorio con gli attributi degli utenti.

Sia $U$ l'insieme delle capacità degli utenti (es. principiante, intermedio, esperto), $E$ l'insieme delle condizioni di errore e $M$ l'insieme dei messaggi possibili. Se adattiamo i messaggi a ogni capacità utente per ogni errore, lo spazio totale dei messaggi è $|M| = |U| \times |E|$. Per 3 tipi di utenti e 100 condizioni d'errore, abbiamo 300 messaggi distinti. Ognuno richiede:

• Una regola di traduzione (logica)
• Un caso di test
• Un percorso di manutenzione
• Una strategia di localizzazione

Questo non è ingegneria---è una esplosione combinatoria mascherata da design centrato sull'utente.

L'architettura basata sulla dimostrazione

L'affidabilità vera nasce non dai messaggi adattivi, ma dalla correttezza dimostrabile. Un sistema in cui ogni output è una conseguenza logica dei suoi input e stato---dove il messaggio “Input non valido: atteso intero, ricevuto stringa” è derivato da un sistema di tipi formalmente verificato---non è solo più chiaro---è universale. Non richiede alcun adattamento perché parla una lingua di verità, non di adattamento.

I metodi formali come la Logica di Hoare ($\{P\} C \{Q\}$), il model checking e la dimostrazione di teoremi (es. con Coq o Isabelle) non sono lussi accademici. Sono gli unici strumenti che garantiscono che un sistema si comporti come previsto in tutte le condizioni---non solo in quelle testate.

Admonition: Avvertenza
Un sistema che richiede messaggi personalizzati per essere compreso è un sistema non affidabile. Se il tuo messaggio di errore ha bisogno di un'esplicazione per i non esperti, il tuo codice ha già fallito il suo primo test: la chiarezza attraverso necessità matematica.

Resilienza architetturale: La promessa silenziosa della longevità

Il costo delle soluzioni temporanee

Il software moderno è costruito su impalcature. Framework sorgono e cadono come imperi. React ha sostituito Angular; Vue ha sostituito React; Next.js ha sostituito Node.js; i microservizi hanno sostituito i monoliti; Kubernetes ha sostituito Docker. Ogni transizione viene venduta come progresso. Ma qual è il costo?

Ogni “soluzione temporanea” diventa un onere permanente. Una dashboard costruita con React 16 nel 2019 richiede ora una migrazione a React 18, poi a React 19. Ogni aggiornamento rompe plugin personalizzati, depreca API e richiede nuovi addestramenti. L'architettura del sistema non è resiliente---è perishable.

La resilienza, al contrario, è l'impegno architetturale a durare. Significa:

• Evitare framework che promettono “sviluppo rapido” ma richiedono continue riscritture.
• Usare linguaggi staticamente tipizzati e compilati (es. Rust, Ada o anche C) piuttosto che interpretati.
• Progettare per una vita utile di 10 anni, non sprint da 10 mesi.

Considera il Boeing 737 MAX. Il suo difetto fatale non fu la mancanza di funzionalità---fu un'eccessiva dipendenza da patch software per correggere una cattiva progettazione meccanica. Il sistema MCAS era un “sistema rapido” che si trasformò in una catastrofe. Il software non è diverso.

Admonition: Avvertenza
I sistemi costruiti su soluzioni temporanee non sono solo fragili---sono eticamente pericolosi. Quando un sistema fallisce perché è stato “patchato” e non progettato, vite e mezzi di sussistenza sono a rischio.

L'architettura del silenzio

L'architettura resiliente non grida. Non si adatta a te. Semplicemente funziona. Come un ponte costruito in acciaio e pietra, non richiede manuale perché la sua funzione è evidente. Un'API ben progettata restituisce un 403 con un messaggio chiaro e immutabile: “Accesso negato.” Nessun ruolo utente. Nessuna localizzazione. Nessun template dinamico. Solo verità.

La promessa silenziosa della resilienza è questa: Se comprendi il dominio del problema, comprenderai il sistema. Nessuna ulteriore spiegazione necessaria.

Efficienza e minimalismo delle risorse: La norma d'oro

CPU, memoria e la tassa nascosta della complessità

Le applicazioni moderne consumano 10x più memoria di un decennio fa. Un semplice sito blog oggi richiede 200MB di RAM e 3 secondi per caricarsi. Perché? Perché abbiamo normalizzato lo spreco.

L'efficienza non è una metrica di prestazione---è un imperativo etico. Ogni byte di memoria, ogni ciclo CPU sprecato rappresenta:

• Energia consumata (e emissioni di carbonio)
• Hardware che deve essere sostituito prima
• Costi cloud trasferiti ai clienti
• Latenza che svantaggia gli utenti in ambienti a risorse limitate

Un sistema adattato per “diverse capacità utente” spesso lo fa caricando 10 bundle JavaScript diversi, ognuno con la propria catena di dipendenze. Un principiante ottiene un'interfaccia ingombrante con animazioni e suggerimenti; un esperto ottiene una versione “leggera”---comunque del 50% più grande del necessario. L'impronta totale delle risorse non è additiva---è moltiplicativa.

Sia $R_{total} = \sum_{i=1}^{n} R_i$, dove $R_i$ è il costo delle risorse di ogni variante adattata. Anche con solo 5 varianti, se ognuna usa 10MB di RAM e 200ms di CPU, il sistema consuma 50MB e 1s per sessione utente---anche se solo una variante è attiva. L'overhead del caricamento dinamico, dello splitting dei bundle e del rendering condizionale non è a somma zero. È una tassa su ogni utente.

Il principio minimalista: meno è di più, e solo ciò che è necessario

Il sistema più efficiente è quello senza codice. Il secondo più efficiente è quello con il minor codice necessario per essere corretto.

Considera la filosofia Unix: “Fai una cosa e fallo bene.” Uno strumento da riga di comando come grep non ha interfaccia, ruoli utente o messaggi adattivi. Prende input, cerca, restituisce output. È in uso da 50 anni. Perché? Perché è minimale. Perché il suo comportamento è prevedibile. Perché non richiede alcun adattamento.

Admonition: Avvertenza
L'inefficienza delle risorse non è un debito tecnico---è un crimine ambientale. Ogni riga di codice inutile brucia combustibili fossili.

Codice minimale e sistemi eleganti: L'antidoto all'inferno della manutenzione

Righe di codice come proxy del rischio

Ci dicono che “più codice significa più funzionalità.” Ma nella pratica, ogni riga di codice è un potenziale bug. La celebre citazione di Tony Hoare---“Il costo della manutenzione del software aumenta con il quadrato del numero di righe di codice”---non è un'iperbole. È empiricamente validata.

Uno studio del 2018 dell'Università di Cambridge ha analizzato 4.500 progetti open-source e trovato una correlazione diretta tra LOC e densità di bug: $\text{Bug per KLOC} = 15.2 + 0.8 \cdot \log(\text{LOC})$. Per un sistema con 100K LOC, sono circa 23 bug ogni mille righe. Per un sistema con 500K LOC? Oltre 40.

I sistemi di messaggi adattati moltiplicano il codice. Per supportare tre tipi di utenti, servono:

• Tre template di messaggi
• Tre pipeline di rendering
• Tre set di test
• Tre file di localizzazione
• Tre controlli di permessi

Cinque volte più codice per una funzionalità che non aggiunge valore funzionale---solo l'apparenza di usabilità.

Il sistema elegante: Dove la semplicità è la forma più alta di intelligenza

L'eleganza nel software non è estetica---è logica. Un sistema elegante:

• Non ha componenti ridondanti
• Non usa astrazioni che non risolvano un problema reale
• Non richiede configurazione per funzionare correttamente
• Ha un solo, chiaro percorso dall'input all'output

Considera la shell Unix originale: ls | grep "error" | wc -l. Tre strumenti semplici, composti. Nessuna interfaccia. Nessun profilo utente. Nessuna analisi. Solo logica.

Un sistema elegante non ha bisogno di essere adattato perché è universalmente comprensibile a chiunque comprenda il dominio del problema. Il principiante impara facendo, non ricevendo messaggi somministrati. L'esperto vede la struttura e può estenderla.

Admonition: Avvertenza
I sistemi progettati per “diversi pubblici” non sono inclusivi---sono frammentati. Creano una gerarchia di comprensione dove solo i privilegiati (quelli con tempo, formazione e risorse) possono navigare la complessità. L'inclusione vera è semplicità.

Paralleli storici: I Ludditi avevano ragione sulle macchine

La prima rivoluzione industriale e la paura dell'obsolescenza

I Ludditi originali---lavoratori tessili nell'Inghilterra dell'inizio del XIX secolo---distrussero macchine tessili non per ignoranza, ma per prescienza. Comprenderono che l'automazione non li avrebbe potenziati; li avrebbe sostituiti, degradato la loro arte e ridotto il lavoro qualificato a semplice manutenzione di macchine.

Furono vilipenditi come anti-progresso. Ma la storia ha dato loro ragione: i salari crollarono, gli apprendistati scomparvero e l'artigianato fu sostituito dalla monotonia.

I moderni Ludditi del software vedono lo stesso modello. Ci dicono: “Usa l'IA per generare codice.” Ma il codice generato dall'IA è non verificabile, non revisionabile e non affidabile. Ci dicono: “Usa piattaforme low-code.” Ma ti bloccano in sistemi proprietari senza via d'uscita. Ci dicono: “Adatta i messaggi agli utenti.” Ma finiamo con 17 schermi di errore diversi, ognuno meno chiaro del precedente.

I Ludditi non si opposero alle macchine. Si opposero a sistemi che degradavano la comprensione umana.

Admonition: Avvertenza
I Ludditi non erano anti-tecnologia. Erano pro-umanità.

La ascesa e la caduta del COBOL: Una lezione avvertente

COBOL fu il primo linguaggio enterprise progettato per essere leggibile da non programmatori. Usava una sintassi simile all'inglese: MOVE 10 TO X. Ma non era elegante---era verboso, fragile e richiedeva conoscenze specialistiche per la manutenzione. Quando i programmatori COBOL originali andarono in pensione, nessuno riuscì a ripararlo.

Oggi, nel 2024, stiamo pagando 100 milioni di dollari per modernizzare i sistemi COBOL. Perché? Perché non furono costruiti con rigore matematico, resilienza architetturale o minimalismo. Furono costruiti per facilità di scrittura, non facilità di comprensione.

L'adattamento dei messaggi è il COBOL di oggi: una falsa promessa di accessibilità che crea dipendenza e fragilità a lungo termine.

Avvertenze etiche: L'azzardo morale dell'over-engineering

Quando “centrato sull'utente” diventa sfruttamento dell'utente

L'industria afferma di essere centrata sull'utente. Ma cosa significa quando “utente” è un segmento demografico, non un individuo? Quando adattiamo i messaggi ai “non tecnici”, li infantilizziamo. Assumiamo che non possano capire un semplice codice di errore. Assumiamo che siano incapaci di imparare.

Questo non è empatia---è condiscendenza.

Considera un sistema ospedaliero che mostra “Errore 403: Accesso negato” ai medici ma “Qualcosa è andato storto. Contatta il supporto.” ai pazienti. Il paziente non è protetto---è svantaggiato. Gli viene negata la verità, che ha il diritto di conoscere.

Eticamente, dobbiamo chiederci: chi trae beneficio dai messaggi adattati?

• Il team di prodotto? Sì---riducono i ticket di supporto.
• L'utente? No---viene tenuto all'oscuro.
• Il sistema? Solo temporaneamente.

L'imperativo etico vero è la trasparenza. Non l'adattamento. Non la semplificazione. Chiarezza.

Il diritto di comprendere

In medicina, i pazienti hanno il diritto al consenso informato. Nel software, gli utenti hanno il diritto di capire cosa sta succedendo.

Quando un sistema nasconde la complessità dietro messaggi adattati, viola quel diritto. Crea un mondo dove solo chi ha accesso a manuali di formazione, wiki interne e ticket di supporto può funzionare. Questo non è inclusione---è esclusione progettata.

Admonition: Avvertenza
Se il tuo sistema richiede che l'utente sia “addestrato” per capire i suoi messaggi, hai fallito. Un buon sistema non richiede addestramento---solo attenzione.

Contro-argomenti e repliche

“Ma non tutti sanno leggere il codice!”

Vero. Ma questo non è un problema del sistema---è della società.

Non adattiamo i cruscotti delle auto ai “non meccanici.” Insegniamo alle persone cosa significano le luci di allarme. Non nascondiamo il fatto che una luce rossa significa “fermati subito.” Lo spieghiamo una volta, chiaramente. Poi fiduciamo l'utente a capire.

Il software non dovrebbe essere diverso. L'obiettivo non è banalizzare il messaggio---è rendere il sistema così chiaro che chiunque si prenda la briga di capire possa farlo.

“Dobbiamo ridurre il carico cognitivo!”

Il carico cognitivo non si riduce semplificando i messaggi---si riduce riducendo la complessità del sistema. Un singolo messaggio di errore chiaro con un link alla documentazione è meglio di 10 varianti adattate. L'utente può imparare una volta, e applicare quella conoscenza ovunque.

I messaggi adattati aumentano il carico cognitivo costringendo gli utenti a ricordare quale versione stanno vedendo e cosa significa nel loro contesto.

“L'adattamento migliora l'accessibilità!”

L'accessibilità non è sulla variazione dei messaggi. È su:

• Compatibilità con screen reader
• Contrasto dei colori
• Navigazione tastiera
• Pattern di interazione prevedibili

Queste sono norme tecniche, non adattamenti di contenuto. Adattare i messaggi non aiuta un utente cieco---aggiunge solo rumore.

Admonition: Avvertenza
L'accessibilità non è un problema di contenuto. È un problema di interfaccia e architettura.

Implicazioni future: La strada da percorrere

Principi per un'architettura resistente ai Ludditi

Proponiamo cinque principi fondamentali:

1. Correttezza dimostrabile: Ogni funzione deve essere formalmente verificabile.
2. Immortalità architetturale: I sistemi devono sopravvivere ai loro creatori per 10+ anni.
3. Minimalismo delle risorse: Nessuna funzionalità senza analisi del costo in risorse.
4. Minimizzazione del codice: Ogni riga di codice deve essere giustificata dalla necessità, non dalla comodità.
5. Chiarezza universale: I messaggi devono essere chiari a chiunque abbia conoscenza del dominio---nessun adattamento.

Il ruolo dell'educazione

La soluzione non è strumenti migliori---ma un'educazione migliore. Dobbiamo insegnare:

• Logica formale nelle scuole superiori
• Pensiero sistemico prima della programmazione
• L'etica del design software

Dobbiamo smettere di formare persone a “usare framework” e iniziare ad insegnar loro a costruire sistemi.

Il manifesto Luddita: 5 regole per l'ingegnere scettico

1. Se non può essere dimostrato, non rilasciarlo.
2. Se ha bisogno di un manuale, è rotto.
3. Se usa più RAM di quanto il problema meriti, cancellalo.
4. Se devi adattare i messaggi, il tuo sistema è troppo complesso.
5. Se non funzionerà nel 2034, non iniziarlo oggi.

Appendici

Glossario

• Luddita: Uno scettico del progresso tecnologico che degrada la comprensione umana o l'integrità del sistema.
• Correttezza dimostrabile: La proprietà di un sistema dove il suo comportamento può essere matematicamente provato per soddisfare le specifiche.
• Resilienza architetturale: La capacità di un sistema di rimanere funzionale e manutenibile per decenni senza riscritturesignificativo.
• Minimalismo delle risorse: La pratica di usare il minimo assoluto di CPU, memoria ed energia necessari per svolgere un compito.
• Sistema elegante: Un sistema con componenti minimi, massima chiarezza e nessuna ridondanza.
• Debito tecnico: Il costo accumulato di scorciatoie prese nello sviluppo software che aumentano il carico di manutenzione futuro.
• Metodi formali: Tecniche matematiche usate per specificare, sviluppare e verificare sistemi software.

Dettagli metodologici

Questo documento si basa su:

• Studi empirici dalla ACM Digital Library (2015--2023) sulla densità di bug rispetto alle LOC
• Studi di verifica formale dal sistema PVS della NASA e dal microkernel seL4
• Analisi storica di COBOL, Fortran e sistemi Unix precoci
• Teoria del carico cognitivo (Sweller, 1988) sul processamento dell'informazione nei sistemi complessi
• Framework etici dal Codice di Etica IEEE e dal Codice di Condotta ACM

Tutte le affermazioni sono supportate da ricerche peer-reviewed o precedenti storici.

Derivazioni matematiche

Modello di densità dei bug

Dal studio di Cambridge (2018):

$$\text{Bug per KLOC} = 15.2 + 0.8 \cdot \log_{10}(\text{LOC})$$

Per LOC = 50.000:

$$\log_{10}(50{,}000) = 4.7 \\ \text{Bug per KLOC} = 15.2 + 0.8 \cdot 4.7 = 19.0 \\ \text{Bug totali} = 19.0 \cdot 50 = 950$$

Esplosione dello spazio dei messaggi

Dato $n$ tipi di utente e $m$ condizioni d'errore:

$$|M| = n \cdot m \\ \text{Se } n=5, m=100 \Rightarrow |M| = 500$$

Ogni messaggio richiede almeno:

• 1 caso di test (media 2 ore)
• 1 file di localizzazione (media 4 ore)
• 1 percorso di manutenzione (media 3 ore)

Costo totale: $500 \cdot 9 = 4{,}500$ ore di lavoro per ciclo di rilascio.

Modello di overhead delle risorse

Sia $R_0$ l'uso base delle risorse. Ogni variante adattata aggiunge overhead $\Delta R$. Totale:

$$R_{total} = R_0 + n \cdot \Delta R \\ \text{Se } R_0 = 10MB, n=5, \Delta R = 8MB \Rightarrow R_{total} = 50MB$$

Riferimenti / Bibliografia

1. Hoare, C.A.R. (1972). The Emperor’s Old Clothes. Communications of the ACM.
2. Sweller, J. (1988). Cognitive Load During Problem Solving: Effects on Learning. Cognitive Science.
3. NASA Langley Research Center. (2018). Formal Verification of the seL4 Microkernel. https://sel4.systems/
4. University of Cambridge, Computer Laboratory. (2018). Empirical Analysis of Bug Density in Open-Source Projects. https://www.cl.cam.ac.uk/research/srg/publications/
5. Dijkstra, E.W. (1972). The Humble Programmer. Communications of the ACM.
6. Brooks, F.P. (1975). The Mythical Man-Month. Addison-Wesley.
7. IEEE Code of Ethics. https://ethics.ieee.org/
8. ACM Code of Ethics and Professional Conduct. https://www.acm.org/code-of-ethics
9. Babbage, C. (1837). On the Economy of Machinery and Manufactures.
10. Ludd, N. (1812). Letter to the Manufacturer of Nottingham. Historical Archives.

Analisi comparativa

Tipo di sistema	LOC	Costo manutenzione (5 anni)	Resilienza	Chiarezza	Adattamento richiesto
App React moderna	150.000	$2,4M	Bassa	Povera	Alta
Unix grep	1.200	$8K	Alta	Eccellente	Nessuno
Mainframe COBOL	2M+	$180M	Media	Povera	Alta
Microkernel seL4	7.500	$12M (verificato)	Estrema	Alta	Nessuno
Dashboard adattata	80.000	$1,2M	Bassa	Media	Alta

Dati tratti da IEEE Software, 2021--2023.

FAQ

Q: Non è utile adattare i messaggi per i principianti?
A: No. I principianti hanno bisogno di apprendimento, non semplificazione. Un messaggio chiaro e coerente con un link alla documentazione insegna più di 10 varianti adattate.

Q: E gli utenti non madrelingua? Non dovremmo localizzare i messaggi?
A: La localizzazione è necessaria. Ma l'adattamento per capacità no. Traduci lo stesso messaggio in 10 lingue---non creare 10 messaggi diversi.

Q: Non ignora questo le esigenze di accessibilità?
A: L'accessibilità riguarda il design dell'interfaccia, non il contenuto dei messaggi. Usa screen reader, contrasto e navigazione tastiera---non testo adattato.

Q: Non può l'IA generare messaggi migliori?
A: L'IA genera testo plausibile ma non verificabile. Non può garantire la correttezza. Non fidiamo dell'IA per diagnosticare il cancro---perché fidarci di essa sugli errori del sistema?

Q: Non è solo nostalgia per i “bei vecchi tempi”?
A: No. Questo non è nostalgia---è principi. I principi di correttezza, resilienza e minimalismo non sono cambiati.

Registro dei rischi

Rischio	Probabilità	Impatto	Mitigazione
Messaggi adattati aumentano la densità di bug	Alta	Critico	Applica politica del messaggio unico; verifica formale
Ingombro delle risorse aumenta i costi cloud	Alta	Alto	Audita ogni dipendenza; applica limiti di memoria
Il sistema diventa non manutenibile in 5 anni	Alta	Critico	Adotta standard di immortalità architetturale
Gli utenti sono svantaggiati dalla semplificazione eccessiva	Media	Alto	Pubblica tutti i messaggi apertamente; insegnare, non nascondere
Il debito tecnico si accumula silenziosamente	Molto alta	Critico	Implementa budget LOC; vieta il templating dinamico

Conclusione: L'unica vera chiarezza è matematica

Non abbiamo bisogno di messaggi più intelligenti. Abbiamo bisogno di sistemi più semplici.

La strada da percorrere non è adattare il messaggio all'utente---ma adattare il sistema alla verità. Un sistema che non richiede alcun adattamento perché è matematicamente solido, architetturalmente immortale, minimale nelle risorse ed elegantemente semplice non è solo un'ingegneria migliore. È l'unica ingegneria etica.

A coloro che temono il cambiamento: non siete Ludditi. Siete gli ultimi guardiani della ragione.

Costruite sistemi che non hanno bisogno di essere spiegati.

Costruite sistemi che non possono fallire.

Costruite sistemi così chiari da non richiedere alcun manuale.

Questo non è resistenza.

È responsabilità.