Pourquoi les développeurs craignent?

La question est agressive, elle vient de l'article Why programmers suck, qui est effectivement assez agressif, mais qui est probablement dans le vrai.

L'argument principal de l'auteur est que la majorité des développeurs (80 à 90%) ne maitrisent pas techniquement les outils qu'ils utilisent, en l'occurrence les langages, les OS, les supports physiques. Et de ce manque de connaissances découlent des erreurs, un code moins efficace et moins lisible. De la complexité inutile, en somme. Le plus grave n'est pas le manque de connaissance, mais le fait de ne pas savoir ce que l'on ne sait pas. Ce n'est pas limité à la création de logiciels, mais c'est particulièrement handicapant.

Une citation qui résume son point de vue

They were just mimicking the mistakes of other programmers–copying code and typing more-or-less meaningless incantations at the machine in the hope that it would behave like they wanted, without any real understanding of the mechanics of the computer, the principles of software design, or the meanings of each individual word and symbol they were typing into the computer.

soit

Ils se contentent de reproduire les erreurs d'autres développeurs, en copiant du code et en écrivant des incantations plus ou moins sensées pour la machine dans l'espoir qu'elle se comportera comme ils l'attendent, sans aucune compréhension réelle des mécanismes de l'ordinateur, des principes du design logiciel, ou de la signification des différents mots et symboles qu'ils saisissent sur l'ordinateur.

Je le rejoins sur le fait qu'une bonne partie des défauts logiciels constatés viennent d'une méconnaissance de la plate-forme. J'ai eu quelques collègues qui tâtonnaient, la plupart d'entre eux en cherchant à mieux comprendre et à s'améliorer. Je tâtonne moi même, et j'espère être sur la même voie. Relire un code un peu ancien, avant que je maitrise réellement l'outil, est parfois source de honte.

Mais je ne pense pas que ce soit le plus grand problème : mon collègue le plus perdu ne comprenait pas bien l'outil utilisé, mais en prime il ne comprenait pas non plus clairement ce qu'il devait faire.

• Il faut déjà avoir bien compris besoin fonctionnel (demandé par le "client").
• Il faut espérer que lui même a correctement exprimé son besoin, qu'il n'a rien oublié d'important, et qu'il ne demande pas plus au logiciel qu'il n'est capable de faire (notamment en terme de respect d'un processus impliquant tant les humains que l'informatique).
• Ensuite le développeur doit voir clairement comment il va implémenter le besoin.
• Plus largement enfin, une bonne connaissance de l'application lui permet d'insérer ce nouveau code tout en respectant son architecture, en allant dans le sens de ce qui a déjà été fait et en l'adaptant.

Donc en plus de la maitrise technique, la compréhension de ce que l'on fait et de ce qui a été fait est nécessaire.

Nous avons un métier complexe et nouveau. Les deux sont probablement liés, dans la mesure où ce métier doit encore mûrir sur plusieurs points. Il nous faut donc continuer à apprendre, et cesser d'ignorer ce que l'on ignore.