Nel tentativo di rendere il vostro software competitivo, un errore comune è aggiungere sempre più funzionalità. Ma a volte nel software, peggio è meglio.
O così dice Richard Gabriel, autore del documento del MIT The Rise of Worse is Better.
Naturalmente, questa affermazione sembra del tutto troppo paradossale per essere di qualche utilità. Ma c’è un buon ragionamento dietro. Qui, spieghiamo la logica dietro il “peggio è meglio”.
Cos’è il “peggio è meglio”?
“Peggio è meglio” è un principio di progettazione del software che sostiene la semplicità rispetto alla funzionalità. Suggerisce che un software limitato e semplice da usare è più attraente di programmi difficili con tutte le campane e i fischietti.
Cioè, la qualità del software non è necessariamente in scala con il numero di caratteristiche e funzioni che avete. “Peggio è meglio” postula che c’è un punto in cui meno funzionalità (cioè ‘peggio’) è preferibile. E la ragione per cui è preferibile è dovuta alla maggiore usabilità e praticità.
Le caratteristiche chiave di “peggiore è meglio”
Messo in pratica, il “peggio è meglio” ruota intorno a quattro caratteristiche chiave.
Semplicità
La caratteristica più importante del “peggio è meglio” è la semplicità. Sia l’implementazione che l’interfaccia del vostro software devono essere semplici. Questo significa che il vostro programma deve essere facile da usare per ottenere il risultato desiderato, preferibilmente con un’interfaccia utente semplice e pulita.
Correttezza
Poi, il design del vostro software deve funzionare correttamente. Questo significa che per ogni input, fornisce l’output previsto, senza errori. (In altre parole, fa quello che vi aspettate che faccia).
Coerenza
La terza caratteristica chiave di un design “peggiore è meglio” è la sua coerenza. Cioè, il design del vostro software non dovrebbe essere eccessivamente incoerente. Questo significa che il design del vostro software dovrebbe essere in qualche modo prevedibile e intuitivo.
Completezza
Infine, “peggiore è meglio” non è un modo per dire software ‘cattivo’ o ‘rotto’. Il vostro programma dovrebbe fornire un’esperienza completa – risolvere l’intero problema che dovrebbe risolvere.
La logica della semplicità
Lo scopo di ogni programma software è quello di risolvere un problema o un punto dolente. Quando mantenete il vostro software semplice seguendo il principio “peggiore è meglio”, vi assicurate di non perdere questa funzione centrale del vostro programma.
Un problema comune nel software è il feature creep. Questo è quando un programma guadagna così tante caratteristiche, campane e fischietti che diventa difficile da usare. L’interfaccia utente diventa disordinata per ospitare la massa di caratteristiche, e il software diventa indisciplinato da usare e mantenere.
Al contrario, un software semplice mantiene la sua funzionalità di base davanti e al centro. Con il peggio è meglio, il programma non farà tutte le cose incredibili che può fare un sistema complesso. Ma fa il lavoro in modo rapido ed efficace. È facile per gli utenti da prendere, capire e usare. Inoltre, è meno codice da mantenere e proteggere per il team di sviluppo.
Rifiutare la complessità
Altre pratiche software supportano il principio di progettazione del software “peggiore è meglio”. Tutte lavorano per rifiutare il software eccessivamente complesso, il feature creep e l’overengineering.
Per cominciare, l’uso di un prodotto minimo vitale (MVP) ti costringe ad evitare di aggiungere caratteristiche extra all’inizio dello sviluppo. Questo può aiutarvi a mantenere chiara la vostra funzionalità di base. Così, quando costruisci il tuo software, puoi assicurarti che le nuove funzioni si adattino al tuo obiettivo del software.
YAGNI (non ne avrai bisogno) è un’altra pratica che può aiutarti a mantenere un design del software semplice, “peggiore è meglio”. Questo perché, con YAGNI, vi assicurate di non costruire alcuna funzione finché non sapete con certezza che è necessaria.
Infine, il metodo MoSCoW può aiutarvi a garantire che ogni caratteristica pianificata sia parte integrante del vostro software, e quindi si inserisce in un design “peggiore è meglio”. È una tecnica di prioritizzazione che ordina le caratteristiche nelle categorie “deve avere”, “dovrebbe avere”, “potrebbe avere” e “non avere”. Per un approccio “peggiore è meglio”, ci si attiene alle caratteristiche nelle categorie “deve avere” e “dovrebbe avere”.
Peggio è meglio
In breve, il “peggio è meglio” consiste nell’evitare la follia del feature creep e dell’overengineering. Riconosce il valore della semplicità e ci ricorda che a volte, meno caratteristiche rendono un’esperienza migliore.