Cos'è il rasoio di Occam e come si applica a una decisione tecnica?
Tra due soluzioni che risolvono lo stesso problema, a parità di risultato vince quella con meno pezzi mobili.
Il rasoio di Occam è il principio secondo cui, tra due soluzioni che risolvono lo stesso problema con risultati equivalenti, va preferita quella che introduce meno elementi nuovi, non necessariamente quella più povera o più economica in assoluto. Applicato a una decisione tecnica diventa un criterio operativo: a parità di esito, la soluzione con meno pezzi mobili costa meno da mantenere nel tempo, ha meno punti in cui può rompersi e richiede meno persone da formare per usarla. Non è un invito a scegliere sempre l'opzione più semplice a prescindere: il principio dice di non aggiungere elementi, sistemi o livelli architetturali che non servano davvero a spiegare o a risolvere il problema. Semplificare sotto il necessario, tagliando qualcosa che il problema richiede, è l'errore uguale e opposto, e si paga tanto quanto la complessità inutile.
Un'attribuzione che vale la pena correggere
La formulazione latina più citata, "entia non sunt multiplicanda praeter necessitatem", viene attribuita quasi ovunque a Guglielmo di Occam, ma non si trova nei suoi scritti superstiti. La voce "Simplicity" della Stanford Encyclopedia of Philosophy osserva che le formulazioni moderne del rasoio sono legate al frate francescano del Trecento solo in modo molto tenue, e rimanda in nota alla ricostruzione di Thorburn (1918), da cui viene sia l'accertamento dell'assenza della formula sia la sua origine: la frase, quasi nella forma oggi nota, compare per la prima volta nel 1639, in un commento scotista del francescano irlandese John Ponce of Cork, quasi tre secoli dopo la morte di Occam. Occam enunciò davvero un principio di parsimonia, ma con altre parole ("numquam ponenda est pluralitas sine necessitate"), e formulazioni quasi identiche circolavano nella scolastica già prima di lui, come quella di Duns Scoto ("pluralitas non est ponenda sine necessitate"): quello che non è suo è solo la formula che porta il suo nome. Il punto non è un vezzo erudito: un principio nato come sintesi tarda di un'idea più antica, e non come regola fissata da un singolo autore, si presta meglio a essere trattato come criterio da applicare con giudizio caso per caso, non come la legge del rasoio di Occam da citare e basta.
Un esempio concreto
Un'azienda manifatturiera con cinquanta dipendenti riceve due proposte per lo stesso problema: l'evasione degli ordini è lenta perché il commerciale non vede lo stock in tempo reale. La prima proposta è una piattaforma di gestione ordini nuova, con il suo abbonamento, la sua interfaccia e un progetto di migrazione dei dati storici. La seconda è collegare via API lo stock del gestionale già in uso a un foglio condiviso che il commerciale consulta prima di confermare un ordine. Se il problema reale è solo la visibilità in tempo reale, e non una funzionalità che al gestionale manca davvero, la seconda soluzione lo risolve con un'entità in meno: nessun nuovo fornitore da cui dipendere, nessun nuovo sistema da far parlare con quello esistente, nessuna persona in più da formare. Sostituire l'intero gestionale sarebbe giustificato solo se il problema fosse più ampio della semplice visibilità, per esempio se il sistema attuale non gestisse più processi che l'azienda usa davvero: in quel caso la domanda cambia e si sposta su quanto debito tecnico accumulato renda la sostituzione l'opzione meno rischiosa, non più.
Perché conta per chi decide
Il rasoio di Occam non è un argomento contro l'investimento tecnologico, è un filtro contro la soluzione proposta perché è quella che chi vende sa costruire, non perché è quella che il problema richiede. Chi valuta un fornitore dovrebbe sempre chiedere cosa succede se si toglie un pezzo della proposta: se il risultato resta lo stesso, quel pezzo non serviva. Lo stesso criterio vale al contrario quando la proposta è la modernizzazione incrementale descritta alla voce strangler fig pattern invece di una riscrittura completa: va scelta perché il problema non richiede di rifare tutto, non perché "rifare tutto" spaventi sempre. Il criterio è lo stesso in entrambe le direzioni: quante entità servono davvero a risolvere questo problema, non quante ne servono a rendere la proposta più scenografica.
Termini correlati
- Debito tecnico · La metafora di Ward Cunningham: ogni scorciatoia nel codice è un prestito, e gli interessi si pagano a ogni modifica successiva.
- Vendor lock-in · Il costo tecnico e contrattuale per lasciare un fornitore: dati, logica e competenze. Si misura prima di firmare.
- Strangler fig pattern · Sostituire un sistema legacy per gradi, instradando il traffico verso il nuovo finché il vecchio non serve più.
- ISV (independent software vendor) · Un'azienda che vende un prodotto software di sua proprietà: è il cliente ad adattarsi al prodotto, non il contrario.
- Time & Material vs Fixed Price · Due modelli di contratto per un progetto di consulenza: prezzo e scope bloccati in anticipo, oppure pagamento sul tempo effettivamente impiegato.
Un termine che ti riguarda da vicino? Parliamone.
CONTATTAMI