Idée principale

Écrire du code coûtait du temps, et ce coût produisait un effet secondaire que personne n'avait décidé : avant d'aller plus loin, il fallait souvent en parler, arbitrer, faire relire, comprendre ce qu'on faisait. La compréhension n'était pas garantie par une discipline, elle était imposée par le prix du geste.

Quand quelques heures suffisent là où il fallait plusieurs jours, ce garde-fou de fait disparaît — et il ne laisse rien derrière lui, parce qu'il n'avait jamais été institué. On peut alors avancer plus vite que sa propre compréhension, sur des écrans qui répondent, une base de données qui existe et une API qui tourne, sans qu'aucun moment n'oblige à savoir pourquoi les choses sont faites ainsi.

La discipline qui manque n'est donc pas une discipline perdue : c'est une discipline qui n'a jamais eu à exister, et qu'il faut écrire pour la première fois.

Pourquoi c'est important

Cela explique pourquoi les équipes les plus expérimentées sont surprises elles aussi. Elles n'ont pas relâché leurs pratiques ; elles ont perdu un mécanisme involontaire sur lequel leurs pratiques s'appuyaient sans le savoir.

Cela oriente aussi le remède : il ne s'agit pas de revenir aux pratiques d'avant, mais de rendre explicite — revue obligatoire, décision d'architecture écrite, budget de compréhension par fonctionnalité — ce que la lenteur produisait gratuitement.

Nuances et limites

Dépasser sa propre compréhension n'est pas toujours un défaut : c'est exactement ce qu'on cherche en exploration, quand on veut voir à quoi ressemblerait une solution avant de savoir si elle vaut. Le danger commence quand l'exploration devient production sans que personne n'ait acté le passage.

Et la lenteur imposait la conversation sans jamais garantir sa qualité : beaucoup de systèmes lents ont été mal compris malgré tout.

Questions ouvertes

• À quel signal une équipe reconnaît-elle qu'un prototype exploratoire vient d'être promu en production sans décision explicite ?