Keep It Simple, Stupid. Quatre mots qui résument l'une des vertus les plus difficiles à pratiquer en développement logiciel : ne pas over-engineer, ne pas anticiper, ne pas compliquer ce qui peut rester simple.
Le principe KISS — Keep It Simple, Stupid — trouve ses origines dans l'US Navy des années 1960. En ingénierie logicielle, il traduit une idée fondamentale : un système fonctionne mieux s'il reste simple plutôt que compliqué. Simple ne signifie pas simpliste ou naïf — cela signifie que la complexité n'est introduite que lorsqu'elle est réellement nécessaire.
Simple ≠ simpliste
La simplicité est un travail. Il est souvent plus facile d'écrire du code complexe que du code simple. Un code simple est lisible, testable, modifiable. Un code complexe est souvent le reflet d'une pensée insuffisamment clarifiée, ou d'une anticipation de besoins qui n'existeront peut-être jamais.
Les pièges de l'over-engineering
- Abstractions prématurées : créer des interfaces et des classes abstraites avant d'avoir deux implémentations concrètes
- Design patterns inutiles : appliquer un pattern parce qu'il est élégant, pas parce qu'il résout un problème réel
- Généricité excessive : concevoir un système capable de gérer tous les cas possibles, y compris ceux qui n'arriveront jamais
- Indirection inutile : multiplier les couches, les wrappers, les adapters pour « flexibilité future »
KISS + YAGNI + DRY
KISS fonctionne de pair avec deux autres principes :
- YAGNI (You Aren't Gonna Need It — n'implémentez pas ce dont vous n'avez pas encore besoin)
- DRY (Don't Repeat Yourself — évitez la duplication).
Ensemble, ils forment un garde-fou contre la complexité accidentelle, que Fred Brooks distingue de la complexité essentielle — celle inhérente au problème à résoudre.
Quand la simplicité est contre-productive
KISS a ses limites. Certains domaines sont intrinsèquement complexes : la finance, la santé, les systèmes distribués à
haute disponibilité. Simplifier à l'excès un domaine riche revient à ignorer sa réalité. Dans ces cas, Domain-Driven
Design et une modélisation fine sont plus appropriés que la parcimonie.
L'objectif n'est pas d'écrire le moins de code
possible, c'est de n'écrire que le code nécessaire.