Chaque logiciel commence simplement. Quelques dossiers, un objectif clair, une petite surface. Ensuite, des fonctionnalités sont ajoutées, les cas extrêmes sont traités et, peu de temps après, vous examinez quelque chose qui nécessite un diagramme pour être compris. Ce n’est pas inévitable, mais il faut de la discipline pour l’éviter.
La partie la plus difficile de la simplicité n’est pas la conception initiale. C'est la résistance constante à la complication. Chaque demande de fonctionnalité, chaque correction de bug, chaque refactorisation est une opportunité d'ajouter de la complexité. Dire non est la compétence de conception la plus importante et la moins célébrée.
Suppression en tant que fonctionnalité
La meilleure version d’un produit comporte souvent moins de fonctionnalités que la précédente. Non pas parce que des fonctionnalités manquaient, mais parce que quelqu'un a eu le courage de supprimer des éléments qui ne méritaient pas leur subsistance. Chaque fonctionnalité a un coût – en maintenance, en charge cognitive, en poids de l’interface.
La simplicité est une pratique, pas une destination. On n’arrive jamais au simple. Vous n’arrêtez pas de demander : est-ce nécessaire ? Est-ce que cela pourrait être plus clair ? Existe-t-il un moyen de résoudre ce problème en supprimant quelque chose au lieu d’ajouter quelque chose ? La réponse est oui, plus souvent que prévu.
