Les dix derniers pour cent

La plupart des logiciels sont finis deux fois. La première fois, c'est quand ça marche sur la machine où on l'a construit. La deuxième fois, c'est quand ça marche partout ailleurs, pour tout le monde, sans que la personne qui l'a construit soit à côté.

C'est entre ces deux moments que les projets meurent, sans bruit.

Ce qu'il y a vraiment dans cet écart

Ce n'est presque jamais quelque chose de brillant. C'est le message d'erreur qui dit ce qui ne va pas au lieu d'afficher undefined. C'est le formulaire qui vous dit quel champ pose problème. C'est la mise en ligne qui n'oblige personne à se souvenir de quatre étapes dans le bon ordre.

Rien de tout ça ne fait un bon effet en démonstration. Et c'est pourtant tout ce sur quoi quelqu'un va tomber un mardi matin, six mois plus tard.

Pourquoi ça compte pour moi

J'ai remis du travail à des gens qui n'étaient pas développeurs, et j'ai vu ce qui se passe quand un petit truc casse et que personne ne sait par quel bout le prendre. Le coût, ce n'est pas le bug. Le coût, c'est la confiance : une fois qu'un outil a mis quelqu'un mal à l'aise devant sa propre équipe, cette personne cesse de lui faire confiance, et ensuite elle cesse de l'utiliser.

Donc je préfère passer une semaine de plus sur les dix derniers pour cent plutôt que de livrer quelque chose d'impressionnant qui devient discrètement le problème de quelqu'un d'autre.