Il y a quelques années, je lisais un livre ancien sur le Forth, un langage assez particulier dans la famille des langages de programmation. L'auteur présentait un des avantages du Forth qui est que l'intégralité du langage et du système est accessible et modifiable par l'utilisateur. Dans sa lancée, il ajoutait qu'il ne comprenait pas tous ces langages qui limitaient ou cachaient des parties de leur fonctionnement, ou qui empêchaient l'utilisateur de faire certaines choses au niveau du système.

La phrase était quelque chose autour de « ces langages prétendent protéger les programmeurs, mais protéger de quoi ? Les programmeurs qui travaillent sur un programme ne sont pas là pour mettre des bâtons dans les roues des autres ! ».

En filigrane, on pouvait comprendre qu'il parlait des langages BASIC ou encore, et surtout, Pascal. Il est toujours amusant d'ailleurs de voir dans ces ouvrages à quel point l'auteur défend son langage de prédilection et critique les autres.

Cette phrase a résonné sur le moment, m'a fait sourire et est restée dans mon esprit. En effet, on peut considérer que l'ensemble des contributeurs à un programme sont là pour aller vers un but commun en toute bienveillance. Il y a probablement des saboteurs de manière exceptionnel, peut-être. Mais c'est passer à côté de ce contre quoi le système protège.

(je parle ici de groupe, mais, petit rappel : être seul ou en équipe sur un programme, c'est pareil)

L'auteur part donc d'un principe : on peut être assez attentif, lorsque l'on programme, au point de ne pas faire d'erreurs. J'ai retrouvé cette idée dans un autre manuel de Forth récemment, sous la forme suivante : « puisque éditer des programmes est complexe, il est préférable de tester chaque nouvelle couche et de ne pas faire d'erreurs ». Et comment faire ? C'est simple, une phrase commence par « Ainsi, si votre analyse préalable du problème à programmer est correcte, et que vous prenez le soin de tester chaque nouvelle couche ... ».

Je pense que déjà à l'époque de l'écriture de ces ouvrages, l'idée qu'il « suffisait de ne pas se tromper » était comprise comme naïve. Ce qui peut potentiellement être valable sur quelques lignes de code est rapidement mis à mal dès que la complexité augmente. Et elle augmente toujours plus vite que l'on ne le pense. De nos jours, on pourrait penser que cette idée est acquise.

Et pourtant non. Sous diverses formes, il m'arrive souvent dans des discussions cette remarque lorsque l'on cherche à mettre en place des outils de protection ou de détection d'erreurs : « ça ne sert à rien, les programmeurs ne sont pas bêtes, ils font attention ! ». Voire parfois avec un peu plus de véhémence : « si un programmeur à besoin de ça, c'est qu'il n'est pas compétent ».

En effet, les contributeurs à un projet font attention, et sont compétents. Sauf quand ils se trompent, et tout le monde se trompe à un moment où à un autre. Peut-être pas souvent, peut-être avec une portée de dégâts limitée, mais toujours. Y compris les auteurs des phrases précédentes.

Mais à quel point est-ce important si on se trompe une fois de temps en temps ? Imaginons une équipe de 10 personnes, chacune d'entre elle se trompant une fois tous les deux mois en moyenne, avec une erreur qui peut « casser » la production, c'est-à-dire avec un impact pour le reste des contributeurs. Cela fait 5 erreurs par mois. Un peu plus d'une erreur par semaine. C'est beaucoup, non ? À mon avis assez pour justifier de ne pas écarter le problème d'un revers de la main.