Quelque part dans votre organisation, il y a une diapositive qui indique de bien faire les choses du premier coup pour réduire les coûts. Je me suis assis dans la pièce où se trouve cette diapositive. Cela reçoit toujours des acquiescements. C’est le genre de phrase avec laquelle personne ne peut contester, car argumenter avec elle revient à plaider en faveur du gaspillage.
Je veux quand même le contester, mais avec précaution, car la diapositive n’est pas tant fausse qu’elle vise la mauvaise cible. Il y a des problèmes que vous comprenez, où « bien faire les choses du premier coup » n'est que du professionnalisme. Et il y a des problèmes que vous ne comprenez pas encore : un travail très incertain, un domaine que vous n'avez jamais touché, un système dont la véritable forme ne se montrera que lorsque vous y serez à fond. Dirigez ce slogan vers ces problèmes et cela cessera d’être de la discipline. Cela devient une exigence selon laquelle vous prétendez connaître la réponse avant d’avoir gagné le droit d’en avoir une. Et faire semblant a un coût : la proposition de budget ne compte jamais.
Cet article concerne l'alternative, que j'ai qualifiée de mauvaise première. Je devrais être honnête sur ce qu’est et n’est pas cette phrase, car il est facile de l’entendre comme une autorisation d’être négligent. Ce n'est pas le cas. Ce n'est pas une autorisation d'écrire des déchets, d'envoyer des déchets non compilables ou de qualifier la paresse de méthodologie. C'est quelque chose de plus calme que ça. Il s'agit simplement de nommer ce qui se passe déjà lorsque vous êtes confronté à un problème que vous ne comprenez pas encore – et de choisir de s'approprier le non-savoir au lieu de le cacher.
Cette distinction est tout le message. Les meilleurs ingénieurs avec lesquels j'ai travaillé ont rarement fait semblant. Ils possédaient ce qu'ils ne savaient pas aussi clairement que ce qu'ils connaissaient. "Faites semblant jusqu'à ce que vous y parveniez" vous dit d'exercer des compétences que vous n'avez pas. "Faites-le mal d'abord" vous dit d'admettre que la première version va être fausse et de commencer à apprendre volontairement au lieu de vous attarder devant un éditeur vierge en attendant une certitude qui ne viendra pas. En fin de compte, la destination n’est pas une astuce de codage. C'est une façon de diriger une équipe. Mais cela commence au clavier, alors permettez-moi de commencer par là aussi.
Lorsque nous avons peur d’admettre que nous ne comprenons pas un problème, nous recherchons des boucliers. Dans les logiciels, les boucliers portent des noms respectables : bonnes pratiques. modèles de conception. Ce sont de véritables outils, et c’est exactement ce qui en fait une si bonne couverture. Personne ne peut vous reprocher d’avoir appliqué SOLID. Personne n’est blâmé pour ...
[Courte citation de 8% de l'article original]