don’t-do-it : Ajouter des technologies (ou pourquoi KISS c’est compliqué)

Aujourd’hui je voudrais parler de principe KISS, mais avant de commencer, je vous propose un exercice.

Vous devez améliorer cette structure LEGO car actuellement elle est dangereuse pour le petit bonhomme. Nous voulons continuer la construction sur la toit blanche, mais pour l’instant la toit n’est pas stable et peut tomber sur la tête du bonhomme. Que faut-il faire pour éviter les blessures ? Le bonhomme doit rester sur place.

Formulez votre réponse avant de continuer la lecture.

La plupart d’entre vous propose soit ajouter un pilier pour la toit soit d’enlever le petit cube installé sous la toit. Les deux solutions sont équivalentes, mais…

La nouvelle publication montre que la majorité préfère d’ajouter des éléments au lieu de les retirer : « People systematically overlook subtractive changes » de 7 avril 2021, https://www.nature.com/articles/s41586-021-03380-y.

Dans cette publication, les répondants ont passé un nombre de tests et la majorité systématiquement préfère l’ajout à l’enlèvement (sur différents tests entre 70% et 90%), alors que les deux sont équivalents en termes de conséquences :

Même après avoir être formés pour identifier ce genre de cas, nombreuses personnes continuent à surcomplexifier des solutions.

Autrement dit, probablement nous sommes face au nouveau biais mental… Dans ce cas, il peut se passer que l’idée de la mise en place d’une nouvelle application / nouveau framework / technologie / etc n’est pas vraiment la seule / optimale solution qui existe dans votre situation et c’est à cause de ce biais que vous ne voyez pas d’autres…

Le principe KISS (« Keep it simple stupid », « Keep it simple, silly », « Keep it short and simple », « Keep it simple and straightforward », « Keep it small and simple ») i.e. « Garde ça simple » est arrivé en informatique depuis les principes des Marines d’Etats Unis (United States Navy) et aujourd’hui il est connu sous différentes formes :

  • YAGNI (« You aren’t gonna need it ») – « Tu n’en auras jamais besoin » ;
  • DRY (« Don’t repeat yourself ») – « Ne faites pas la même chose deux fois » ;
  • UNIX way ;
  • Code bloat ;
  • « Fatware » (N. Wirth) ;
  • etc.
c1a.png

Vu le nombre de (re)formulations, nous pouvons supposer que le principe n’est pas si simple – même les personnes qui doivent elles-mêmes réaliser les systèmes surcomplexifiés, continuent de le faire. 😉 Que pouvons-nous dire de décisions d’architectes d’entreprise ou de manageurs qui ont la possibilité de choisir la solution plus complexe sans conséquences directs pour eux-mêmes ?

Voici l’ensemble de syntax du langage de programmation Smalltalk :

…et voici une spécification de JavaScript (860 pages) :

Est-ce que vous pensez que JavaScript 2030 sera un langage qu’on va apprendre durant toute notre vie ? On ajoute, on ajoute, on ajoute…

Il y a probablement aussi une autre raison, pourquoi on complexifie les choses en IT…

Dans une recherche de B. Galef (« Social Transmission of Acquired Behavior », 1976) on trouve que même les singes rhésus peuvent apprendre le comportement qui peut leur faire mal. L’idée est suivante : prenons un singe et un objet que le singe veut manipuler (ex. banane) ; développons un peur d’une telle manipulation (via punition). Maintenant prenons un autre singe du même sexe et du même âge (« naïf ») et mettons-les ensemble. Le singe « naïf » apprendra vite que la manipulation avec l’objet en question est dangereuse (par le comportement d’autre singe). Une fois nous les séparons, le singe qui était « naïf » limitera les manipulations avec l’objet (sans savoir, pourquoi).

Vous me dites que nous ne sommes pas si primitifs que les sanges. Cependant, dans le monde des entreprises il existe aujourd’hui une certaine tendance de considérer les applications comme les « actifs ». Ainsi, l’ajout d’un actif dans l’écosystème est récompensé, alors que la suppression… peut être punie.

Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher

Antoine de Saint-Exupéry, Terre des hommes

Pensez à Saint-Exupéry quand vous rédigez votre prochain appel d’offres.

Bonne santé à vous et à vos systèmes !