Dans un texte de 1995 intitulé A Plea for Lean Software («Plaidoyer pour des logiciels maigres»), l’informaticien Niklaus Wirth réitère le problème de la complexité croissante des logiciels, conséquence de l’intégration débridée de fonctionnalités et, surtout, d’une culture de la conception défaillante. Wirth cite, non sans pointe d’humour, la «loi» énoncée par Martin Reiser1:
Les logiciels ralentissent plus rapidement que le matériel devient plus rapide.
Qu’est-ce qui explique cela?
L’une des causes primaires de la complexité réside dans le fait que les fabricants de logiciels adoptent sans regard critique presque toutes les fonctionnalités que veulent les utilisateurs. Toute incompatibilité avec le concept système d’origine est ignorée ou n’est pas reconnue, ce qui rend le design plus compliqué et son utilisation plus encombrante.
Une telle attitude, consistant à intégrer sans esprit critique des fonctionnalités qui accroissent substantiellement la complexité du système et sa consommation énergétique (mais aussi l’entretien nécessaire à son fonctionnement, comme les aspects liés à la sécurité, la fiabilité, la conformité légale, etc.), engendre des conséquences bien néfastes, comme l’obsolescence continuellement accélérée du matériel informatique. Si les ordinateurs paraissent ralentir avec le temps, ce phénomène doit être nuancé: c’est la croissance de la charge imposée sur la même capacité de calcul qui donne une telle impression.
La croissance non contrôlée de logiciels est également acceptée parce que les clients n’arrivent pas à faire la distinction entre des fonctionnalités essentielles et celles qui seraient simplement «agréables à avoir». Des exemples de cette dernière comprennent: le chevauchement arbitraire des fenêtres que suggère la métaphore du bureau, acritique mais largement adoptée; ou les icônes sophistiquées qui décorent l’affichage à l’écran, comme des boîtes postales et des bacs poubelles qui sont davantage améliorés par le mouvement visible des items sélectionnés vers leur ultime destination. De tels détails sont mignons, mais non essentiels, et comportent un coût caché.
La conception méthodique comme remède à l’ébriété logicielle
«L’ébriété logicielle» repose, comme l’expression le suggère, sur des lacunes de jugement ou de conception. L’accroissement régulier de la puissance de calcul dans les générations successives d’ordinateurs (en étroite corrélation avec la loi de Moore2) a aussi pour effet de réduire la pression quant à la qualité des écritures (le code des programmes en l’occurrence):
Bill Gates a fait une observation similaire, mais a dit que le résultat net consiste à conserver la même vitesse d’un système, pas de la diminuer. Gates spéculait sur plusieurs raisons: les programmeurs ajoutent de plus en plus de fonctionnalités, mais codent d’une manière de moins en moins efficiente à mesure que la capacité du matériel (hardware) s’accroît. Se soucier moins de l’efficience des logiciels permet de rendre leur production moins coûteuse. C’est un exemple où la loi de Moore permet d’atteindre un compromis en diminuant les coûts ailleurs que dans la technologie des puces. Un grand nombre d’applications et de systèmes d’exploitation contiennent désormais des dizaines de millions de lignes de logiciel en tant qu’effet secondaire de la loi de Moore.
La clé (ou «prix à payer» comme le désigne Wirth) pour contrer la complexité résiderait donc dans la conception méthodique, car réfléchie (en intégrant une gamme de considérations provenant de divers horizons), disciplinée (en adhérant rigoureusement à des principes éprouvés), progressive (par étapes sciemment décomposées), itérative (par rondes successives). Une telle rigueur se trouve néanmoins court-circuitée par des impératifs du marché, comme la recherche de rentabilité à court terme.
Un design méthodique, par exemple, est apparemment indésirable parce que les produits développés prennent trop de temps avant leur mise en marché. Les techniques de vérification analytique et de mise à l’épreuve sont encore plus mal en point; de plus, ces méthodes requièrent un calibre intellectuel plus élevé que la coutumière approche par essais et erreurs (try and fix it). […] Quand «n’importe quoi fera l’affaire» est le modus operandi, la méthodologie et la discipline sont les premières à souffrir.
Loi de Reiser: Wirth souhaitait explicitement remédier au problème énoncé par Martin Reiser avec son projet Oberon (un système d’exploitation): «La compacité et la structure régulière, ainsi qu’une attention minutieuse à l’implémentation efficiente de détails importants, semblent être la clé du développement économe. Avec le Système Oberon, nous souhaitons réfuter la loi de Reiser, laquelle a été confirmée par virtuellement toutes les sorties récentes de systèmes d’exploitation: malgré les avancées en matière de matériel, celui-ci ralentit plus rapidement que les logiciels deviennent plus lents.» (Compactness and regular structure, and due attention to efficient implementation of important details appear to be the key to economical software engineering. With the Oberon System, we wish to refute Reiser’s Law, which has been confirmed by virtually all recent releases of operating systems: In spite of great leaps forward, hardware is becoming faster more slowly than software is becoming slower.) ↩︎
Loi de Moore: Gordon E. Moore (dans son article de 1965) prévoyait que la densité des processeurs manufacturés continuerait de s’accroître à raison d’un facteur de deux tous les deux ans. Cette tendance s’est effectivement concrétisée pendant plusieurs décennies. Il est intéressant de remarquer le phénomène de boucle rétroactive: plus l’offre computationnelle s’accroît (des puces plus petites et plus puissantes), plus la demande en tâches computationnelles s’ensuit, dans une course effrénée où l’une et l’autre s’échangent la tête (la capacité de calcul est rattrapée, puis devancée par la demande, et vice-versa). Voir John L. Gustafson, «Moore’s Law» dans David Padua (éd.) Encyclopedia of Parallel Computing, Springer, New York, 2011, https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_81. ↩︎