Ogni pezzo di software inizia in modo semplice. Pochi file, uno scopo chiaro, una piccola superficie. Quindi le funzionalità vengono aggiunte, i casi limite vengono gestiti e in breve tempo ti trovi davanti a qualcosa che richiede un diagramma per essere compreso. Questo non è inevitabile, ma ci vuole disciplina per prevenirlo.
La parte difficile della semplicità non è il progetto iniziale. È la continua resistenza alle complicazioni. Ogni richiesta di funzionalità, ogni correzione di bug, ogni refactoring è un'opportunità per aggiungere complessità. Dire di no è l'abilità progettuale più importante e la meno celebrata.
Rimozione come funzionalità
La versione migliore di un prodotto spesso ha meno funzionalità della precedente. Non perché mancassero delle funzionalità, ma perché qualcuno ha avuto il coraggio di togliere cose che non gli guadagnavano il mantenimento. Ogni funzionalità ha un costo: nella manutenzione, nel carico cognitivo, nel peso dell'interfaccia.
La semplicità è una pratica, non una destinazione. Non arrivi mai al semplice. Continui a chiederti: è necessario? Potrebbe essere più chiaro? C'è un modo per risolvere questo problema rimuovendo qualcosa invece di aggiungere qualcosa? La risposta è sì, più spesso di quanto ti aspetteresti.
