Lorsque vous travaillez sur un programme, sur les parties difficiles et délicates, vous appliquez vos meilleures heuristiques, vous déployez tout le processus de prévention des défauts. Sur les parties faciles, vous allez plus vite, vous relâchez la discipline sur le processus.

Vous faites ainsi parce qu’un processus discipliné prend du temps et de l’énergie (oui, moins qu’un programme complètement buggué, mais tout de même), et que tout projet de développement est structurellement, dès le jour 1, en retard.

À appliquer l’approche exhaustive sur tout le projet, vous pêcheriez par lenteur. Et vous manqueriez des jalons et des opportunités. C’est ce qu’ont compris tous les start-upers, qui comme on le sait codent à la Rache exactement pour cette raison.

Mais à ne rien appliquer, c.à.d à prendre à la “légère” l’ensemble du programme, votre projet tomberait en échec. Ce n’est pas la peine d’arriver pile poil à la date d’échéance de la démo tant promise et tant redoutée, si c’est pour présenter un produit tellement peu fiable qu’il va faire rire (ou râler).

La question devient donc : quand faut-il aller “vite”, et quand faut-il se discipliner ? Ceux qui n’en savent rien mais se lancent tout de même ont parfois de la chance, et font un produit qui réussit à séduire des capital-risqueurs. On entend alors sur les media et les réseaux sociaux beaucoup d’éloges de la simplicité et de la vitesse comme si l’ingénierie s’arrêtait à une affaire de style. Logique, puisque ce qui va vite et se renouvelle crée de l’attention.

On peut trouver injustifié et même cruel de demander aux candidat·es à un poste de Dev de coder ou d’expliquer un algorithme. Je n’ai pas d’avis sur la question mais je trouve l’expérience intéressante à partir du moment où l’enjeu n’est pas de savoir si la personne est très intelligente (des gens très intelligents peuvent produire des jugements et conduire des actions catastrophiques, ça se voit tous les jours) ou si la personne connaît par cœur son Knuth ou son Sedgewick, mais d’examiner la réponse à cette question : Quand c’est complexe tu t’y prends comment ?

Peut être que nos problèmes de fiabilité (ou de “qualité”, de “productivité”, de “valeur métier”, choisissez votre poison), ne viennent pas tant du fait que les outils et les méthodes ne marchent pas (“TDD est mort”, “la revue de code est une perte de temps”, “arrêtez avec les tests”, “faites du Clean Code”, “puisque je vous dis que vous n’avez que faire de testeurs”, etc). Tout ces outils et méthodes marchent comme ils le peuvent. Le problème vient plutôt d’une cruciale absence de jugement stratégique ou tactique.

Peut-être que nous plantons nos projets, non du fait d’une méthode défaillante, mais seulement parce que nous prenons les raccourcis ou les accélérations aux mauvais moments.

Comme le dit Weinberg, le problème d’une heuristique, c’est qu’elle ne vous dit pas quand arrêter.

Publié sur Linked In le 23/12/2024