Il y a 25 ans, j’ai travaillé pour un temps dans une société qui réalisait des développements au forfait. Cette société comprenait une Direction de la Qualité, laquelle avait mis en place une méthodologie de développement dont l’essentiel tenait à peu près dans 5 gros classeurs. L’un d’eux contenait la prescription suivante : 

En C, l'ordre d'évaluation des paramètres d'une fonction
n'est pas garanti par l'éditeur du compilateur,
et n'est donc pas portable d'un sytème à l'autre.
Par conséquent les expressions logiques telles que :

if ( exprA && exprB && exprC ) {

sont interdites et doivent être remplacées par des IFs imbriqués :

if (exprA) {
 if (exprB) {
  if (exprC) {

Ça m’a laissé perplexe. Sur le moment je me suis posé plusieurs questions :

  • d’où vient cette règle de programmation erronée ? (son auteur semble confondre l’ordre d’évaluation des paramètres à l’appel d’une fonction, et l’ordre d’évaluation d’une expression logique en court-circuit, qui se fait par définition de la gauche vers la droite.)
  • est-ce que l’auteur de ce guide à lu au moins un document de référence sur le C ?
  • est-ce que les documents auquels je me réfère sont dans le faux, et l’auteur de la prescription dans le vrai ?
  • est-ce que son équipe est tombée sur un compilateur C buggué sur une machine particulière ?
  • combien de projets existants ont été affectés par cette règle ?
  • que se passe t’il si j’intègre un projet de développement en C ?
  • que se passe t’il si je décide de me conformer à cette règle dans mon code ?
  • est-ce que je ne devrais pas plutôt suggérer un amendement au classeur no 3 “Méthodologie des développements en C” ?
  • comment va se passer cet amendement ?
  • de quoi la direction de la qualité va avoir l’air si ça se sait ?
  • de quoi est-ce que j’aurai l’air ?
  • est-ce que j’ai choisi la bonne entreprise et combien de temps vais-je y travailler ?

Aujourd’hui je me pose de nouvelles questions :

  • Si chaque projet contient des instances de dette technique, est-ce que cette page de la méthodo ne constituait pas en elle-même une factory de dette technique ?
  • On pense la DT comme un passif qui concerne la qualité interne d’un logiciel, mais dans ce cas précis, n’est-ce pas plutôt un passif lié au processus de l’entreprise ?
  • Dans cette situation, la Direction de la Qualité disposait d’un certain effet de levier. Comment aurait-elle pu remédier à la dette ainsi générée ? La prévenir ?
  • C’était il y a 25 ans. Qu’est-ce qui a remplacé les classeurs méthodologiques dans les entreprises aujourd’hui ?
  • Est-ce qu’il revient à chaque équipe projet de rétablir tant bien que mal la cohérence de l’état de l’art de l’entreprise ?
  • Quelles marges de manœuvres permettraient de préserver un état de l’art non pas figé, mais cohérent en regard des objectifs et des contraintes changeantes de l’entreprise ?

Stay Tuned !

publié sur Linked In le 16/02/2023