Les techniques de néo-management en vogue depuis les années 80 cherchent à tout prix à faire du personnel une ressource comme les autres. C’est-à-dire que les travailleurs doivent être aussi souples et interchangeables qu’une gomme ou un boulon. Dans le domaine du développement logiciel, une méthode pour arriver à cet objectif discutable est de focaliser le travail des développeurs non plus sur le produit demandé par le client, mais sur l’outil de production qui permettra effectivement de satisfaire le client mais aussi les prochains, et à moins cher que si cet outil n’existait pas (mais facturé autant, bien entendu) Ainsi, on n’a besoin de moins en moins d’experts techniques et de plus en plus de travailleurs moins qualifiés pour un produit de qualité équivalente. C’est le progrès, et bien logique. Un compilateur ne fait ni plus ni moins que ça : il génère du code assembleur que peu maîtrisent à partir d’un langage plus facile d’accès, et donc pour lequel on trouvera plus de main d’oeuvre moins essentielle.
L’intéressant là-dedans, est de voir la communication associée du middle management (Petits Chefs en français) pour justifier des dépassements financiers ou le génie dont a su faire preuve l’entreprise. Enfin, plutôt dont ils ont su faire preuve, quand on les écoute. La métrique fondamentale, c’est le nombre de lignes de code générées. Plus il y en a, mieux c’est. Forcément : l’investissement dans le coût de développement de l’outil de génération est d’autant mieux amorti qu’on s’en sert beaucoup. Et cela rend encore plus judicieux l’investissement initial. Toutes les lignes que l’on génère, c’est autant de lignes que l’on n’a pas à écrire à la main, donc de développeurs à payer. Générer des lignes, c’est améliorer la productivité des équipes.
Tout ceci est complètement vrai, toutes choses étant égales par ailleurs. Ce qui n’est bien entendu pas le cas ici. On oublie (volontairement) au moins une chose : la qualité du code généré n’est pas la même. Pire, elle n’est pas contrôlée sur le long terme. L’architecte a prévu un schéma de génération, qui se défend totalement lors des premiers usages de l’outil. Plus le projet avance, plus il y a de choses à faire entrer dans le générateur, et donc il en sort de plus en plus de code. Peut-être que le schéma de génération initial ne s’applique plus quand on génère trois fois plus de code qu’initialement prévu ? Tout le monde s’en moque. Je dirais même qu’il ne vaudrait mieux pas que ça se sache. Ça fait déjà quatre mois qu’on dit générer 85% du code, on va pas faire s’effondrer cette métrique en dépensant des sous qui plus est ! Et l’équipe serait mécaniquement moins productive. Non, non et non, le schéma de génération, aussi mauvais soit-il devenu, ne doit pas être amélioré.
Aussi malhonnêtes soient-ils, je n’ai jamais vu aucun Petit Chef demander à ce que l’on dégrade encore plus le schéma de génération pour générer 200 lignes quand on en générait 100. Pourtant cette stratégie ferait clairement leur beurre. Mais sont-ils simplement capables d’avoir cette (une ?) idée ?