Le développement n'est qu'un rogue-like IRL

Die & Retry

La résistance au reset, notre principal biais

Ce qui rend le développement douloureux, c’est souvent notre résistance au reset.

Les managers appellent ça le sunk cost fallacy, le biais des coûts irrécupérables. On continue d’investir dans quelque chose qui ne fonctionne pas uniquement parce qu’on y a déjà mis du temps, de l’argent ou de l’énergie. Abandonner ressemble à du gâchis. Alors on continue. Et on aggrave le gâchis.

Dans le code, ce biais prend des formes très concrètes. On s’accroche à une architecture bancale parce qu’elle a pris trois semaines à écrire. On refuse de refactoriser parce que “ça marche comme ça”. On continue sur une mauvaise piste parce que s’arrêter ressemble à un aveu d’échec.

Dans un rogue-like, cette attitude te tue systématiquement. Le bon joueur sait quand lâcher un build qui ne fonctionne pas. Il sait pivoter sans dramatiser. Il reset sans que ça ressemble à une défaite.

Les meilleures équipes Agile font pareil. Quand un sprint rate ses objectifs, elles ne cherchent pas à se justifier. Elles tiennent leur rétrospective, identifient ce qui a mal tourné, ajustent le plan, et recommencent. Le reset n’est pas une punition, c’est une fonctionnalité du système.

Les meilleurs développeurs font pareil individuellement. Ils posent leur ego, jettent leur code sans nostalgie quand c’est nécessaire, et recommencent avec les apprentissages de la run précédente.

Le reset n’est pas la fin. C’est le début de la prochaine run.

Ce que “die & retry” signifie vraiment

Die & retry, ce n’est pas une invitation au masochisme. C’est une philosophie de progression.

Ça signifie que l’échec n’est pas un état terminal, c’est une étape. Que la douleur d’un projet qui foire n’est pas du temps perdu, c’est du capital accumulé. Que la compétence n’est pas un don, c’est la somme de toutes les fois où tu as pris un couloir sombre, rencontré un boss que tu ne connaissais pas, et appris son pattern à tes dépens.

Le développeur que tu admires n’est pas quelqu’un qui ne se plante jamais. C’est quelqu’un qui a fait assez de runs pour reconnaître les patterns rapidement, pour savoir quand fuir et quand se battre, pour transformer chaque mort en données utiles.

L’équipe Agile mature n’est pas celle qui ne rate jamais ses sprints. C’est celle qui a assez raté pour tirer parti de chaque échec, ajuster son rythme, et livrer avec une régularité que les autres trouvent presque magique. Ce n’est pas de la magie. C’est du game design bien intériorisé.

Lance ta prochaine run

Si tu traverses en ce moment un projet difficile, une codebase qui te résiste, une techno que tu ne maîtrises pas encore : tu n’es pas en train d’échouer. Tu es en train de jouer.

Tu accumules de l’expérience. Tu apprends les patterns de ce donjon particulier. Tu construis ton build, run après run, sprint après sprint.

Et un jour, tu reviendras dans un couloir similaire, et tu sauras exactement quoi faire.

Die & retry. C’est comme ça qu’on devient bon.