Le blog d'Archiloque

Loi de Brooks, mépris & jeux vidéo

Voici un tweet que j’ai vu il n’y pas longtemps, et dont je crois déjà vu des variations plusieurs fois :

On est en 2022 et il y a encore des responsables qui, face à un projet en retard, réagissent en embauchant plus de personnes pour développer, demandent aux équipes de travailler plus longtemps, et arrêtent de faire des tests. Ces trois choses vous feront prendre encore plus de retard.

Deux choses me font réagir dans ce tweet.

La formulation

Dans ce tweet on sent un mépris de la part d’une personne qui sait (et qui sait depuis longtemps à priori) envers des personnes qui ne savent pas, alors qu’elle devraient savoir.

En passant, si vous non plus vous ne savez pas il s’agit de la loi de Brooks, qui vient du Mythical Man-Month de Frederick Brooks, comme ça vous aussi vous faites partie du club.

Tweeter ce genre de chose est, je pense, moyen commode de souder un groupe, le groupe des personnes qui savent et qui se sont heurtées à des personnes qui devraient savoir (alors qu’on est quand même en 2022), on au moins qui se reconnaissent dans ce sentiment.

Quand on soude un groupe sur le fait d’affirmer son mépris des gens qui ne savent pas, je pense qu’on obtient un groupe de personnes qui méprisent les gens qui ne savent pas, ou au moins pour qui mépriser les gens qui ne savent pas est un comportement qui ne pose pas problème.

On peut décider ou pas de faire partie de ce genre de groupe, tant qu’on ne me force pas à en faire partie, cela ne me dérange pas.

Par contre ce qui me dérange c’est qu’à voir régulièrement ce genre de tweet, certaines personnes en viennent à penser que cette habitude est la norme chez les personnes qui ont connaissance de la loi de Brooks, et que par conséquent on m’assimile à ce groupe même sans en faire partie.

(La personne en question est un “thoughleader” très expérimenté je ne me permettrait pas sinon ce genre de commentaire.)

Le contenu

L’autre chose qui m’interpelle c’est le contenu du message.

Cela recoupe en partie ce que j’ai déjà pu écrire sur les pratiques de développement des jeux vidéo.

Dans les jeux vidéo la pratique du crunch, c’est à dire de travailler sur des horaires étendus jusqu’à 70 heures par semaines, est une habitude quand un projet est en retard.

Je ne dis pas que c’est une bonne chose, je pense même l’inverse, mais que cette pratique existe.

L’autre pratique habituelle est de déplacer des personnes d’un projet en cours pour le mettre sur un projet en retard afin de le faire aboutir plus vite.

Je ne pense pas que les entreprises qui développent des jeux vidéo ne se trompent jamais. Mais d’un autre côté, si ces deux pratiques ne fonctionnaient pas, je me dis qu’elles s’en seraient aperçues depuis le temps, et qu’elles ne seraient pas aussi répandues.

(Et je ne pense pas que leur dire que Frederick Brooks a inventé une loi en 1975 qui dit que ce qu’elles font ne peut pas fonctionner suffise.)

Certes Frederick Brooks est un auteur culte, et on peut avoir très envie que la loi de Brooks soit vraie (car cela nous arrangerait quand même beaucoup).

Mais l’exemple des jeux vidéo me fait penser que cette loi n’est peut-être pas si vraie, et qu’il faudrait peut-être creuser le sujet, même au risque que la conclusion ne soit pas celle que je voudrais.

Ça serait la différence entre “ces pratiques peuvent aider pour votre problème de retard mais elles peuvent faire du mal aux personnes, donc je vous conseille fortement de ne pas les mettre en œuvre” et “ces pratiques n’ont aucune chance d’aider”.

En attendant j’ai décidé de ne plus citer la loi de Brooks.

Combien de temps reste-t-il ?

En réponse à cet article, une personne a suggéré que les personnes ont tendance à sous-estimer le retard d’un projet.

Pour déterminer si cela vaut la peine d’ajouter des personnes à un projet, il faut savoir si le coût de les ajouter au projet[1] est supérieur à ce qu’elles vont pouvoir apporter au projet avant qu’il ne se termine.

Si un projet est en retard et qu’on pense qu’il est peut-être presque terminé, cela peut mener à penser qu’il n’est plus la peine d’ajouter des gens, alors qu’une estimation plus juste de ce retard mènerait à un choix inverse.

Mon expérience à ce sujet est qu’il est souvent plus facile dans une organisation d’annoncer des petits retards successifs, comme si on découvrait peu à peu l’ampleur du problème, plutôt qu’un gros retard qui correspond à ce que les personnes ont vraiment en tête.


1. C’est-à-dire de les faire monter en compétence pour qu’elles soient efficaces, ce qui prend du temps aux personnes qui sont déjà sur le projet, alors que ce temps pourrait être utilisé à faire avancer le projet