Le réflexe
Chaque fin de semaine, en toute bonne foi, une question a sa place fixe à l’ordre du jour.
“On a shippé quoi cette semaine ?”
Le réflexe builder
“Montre-moi ce qui a rétréci.”
Pourquoi
Tout ce que cette section demande est invisible sur un écran de démo. L’architecture ennuyeuse. Les trois cents lignes retirées. L’après-midi passé à lire un driver de base de données. Le chrono qui a terminé en dix minutes un débat de quarante.
Alors le calcul se fait tout seul. Un nouveau service donne un slide avec un schéma dessus. En retirer un donne un diff plein de lignes rouges et une question polie sur ta semaine. Personne n’a besoin de décider que supprimer n’est pas récompensé ici. Quatre vendredis suffisent pour que tout le monde le comprenne et arrête d’en parler.
La complexité que tu as récompensée ne part pas quand part celui qui l’a construite. Elle reste sur le pager de celui qui sera encore là dans deux ans, et à ce moment-là elle ressemble à de la malchance plutôt qu’à une série de choix que tu as applaudis.
Les ingénieurs ne peuvent pas réparer ça par le bas. Choisir la version ennuyeuse est un risque de carrière dans une équipe qui compte les ajouts, et lire du code source un après-midi ressemble exactement à un après-midi passé à lire. C’est toi qui fixes le prix des deux, dans ta réaction, pas dans ton document de valeurs techniques.
À essayer
→ Donne aux suppressions la même place qu’aux lancements, même revue, même ton. Composants retirés, dépendances abandonnées, code supprimé, chacun avec le nom de celui qui l’a fait. → Une fois par mois, finance un après-midi sans rien à montrer. Une personne, une dépendance sans laquelle le produit ne tourne pas, qui lit le code. Elle raconte ce qu’elle a trouvé, pas ce qu’elle a construit. → Quand tu valides une architecture, écris qui la portera dans deux ans. Un nom, dans le document. Puis vérifie si cette personne était dans la salle.
À discuter
C’est quoi la dernière chose pour laquelle quelqu’un ici a été félicité et qui a rendu le système plus petit ?