Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Élaborer des spécifications d'architecture et simuler mentalement les cas d'erreur est un exercice agréable. Le code dans notre tête est parfait et sans bug. Mais si les réflexions se prolongent sans ouvrir l'éditeur, il ne s'agit plus de prudence, mais simplement de peur de l'échec. Les documents de conception géants créés pour éviter l'incertitude s'effondrent dès le premier changement d'exigence au moment d'entamer le développement.
A l'attention des développeurs qui perdent leur temps prisonniers de la paralysie de l'analyse, voici une méthode de travail structurée pour briser le perfectionnisme et lancer un prototype dès aujourd'hui.
Comparer toutes sortes de frameworks et d'architectures avant d'écrire une seule ligne de code entraîne une surcharge cognitive intense. S'obstiner à gérer des erreurs ayant moins de 0,1 % de chance de se produire ou empiler des couches d'abstraction alors même que les exigences n'ont pas encore été définies relève d'une réaction classique d'aversion à la perte.
Selon une étude menée par McKinsey et Leadership IQ auprès des entreprises du classement Fortune 500, le temps perdu en raison de l'indécision et d'une analyse excessive dépasse 53 000 jours par an. En termes de coûts de main-d'œuvre, cela représente 250 millions de dollars partis en fumée sans le moindre résultat. La productivité individuelle des développeurs est également rognée de plus de 40 % à cause de l'optimisation prématurée.
Lorsqu'on sent que la simulation mentale s'éternise, il faut provoquer un arrêt d'urgence par le biais d'un système. Il suffit d'appliquer au quotidien le modèle de solution "spike" (pic de recherche) de l'Extreme Programming (XP) :
Rester bloqué en phase de conception pendant deux semaines ne signifie pas que les spécifications manquent, mais plutôt qu'il y a un manque de contexte d'exécution. Dans ce cas, il faut fermer tous les documents de conception et imposer un time-boxing de 30 minutes.
Un prototype d'une complétude de 30 % fait l'impasse sur la gestion des erreurs, la connexion à la base de données et le raffinement de l'interface utilisateur. On vérifie uniquement si la saisie de valeurs génère le résultat escompté. C'est précisément la raison pour laquelle les équipes produit de la Silicon Valley tiennent leurs réunions avec des prototypes fonctionnels plutôt qu'avec des documents d'exigences abstraits. L'incertitude ne disparaît qu'en manipulant directement l'écran.
Parlons du coût du retard (Cost of Delay). Si quatre ingénieurs payés 2 025 dollars par semaine enchaînent les réunions d'architecture pendant deux semaines, cela engendre une perte directe et indirecte de 16 200 dollars.
| Critères d'évaluation | Développement axé sur les spécifications | Développement axé sur le prototype | Effet |
|---|---|---|---|
| Définition des exigences initiales | 2 à 4 semaines (rédaction de documents) | 30 minutes à 1 jour (création d'un spike) | Réduction de 90 % du temps |
| Réunions de modification du design | En moyenne 8 à 12 (débats abstraits) | En moyenne 2 à 3 (basées sur des démos) | Réduction de 70 % des réunions |
| Correction des erreurs d'orientation | Reconstruction totale de la structure | Abandon du brouillon de 30 minutes | Minimisation des coûts de retravail |
| Vitesse de revue des PR | Apparition de goulots d'étranglement | Publication anticipée d'une Draft PR | Augmentation de 30 % de la vitesse de revue |
Lorsque la pensée et l'implémentation se mélangent, on ne cesse de regarder en arrière tout en écrivant le code. C'est pourquoi il faut diviser nettement son temps de travail journalier entre une phase d'analyse et une phase d'implémentation pure et simple. C'est le même principe que la règle "temps fixe, périmètre variable" de la méthodologie Shape Up de Basecamp.
Face à une zone de blocage, plutôt que de sombrer dans une profonde contemplation, on suit le concept de la "dette délibérée et prudente" du quadrant de la dette technique de Martin Fowler. S'il s'agit d'un code facilement modifiable par la suite, il vaut mieux choisir le contournement le plus simple dès maintenant et faire un commit.
Jeff Bezos a affirmé qu'il fallait prendre des décisions et avancer lorsque le niveau de certitude atteint environ 70 %. Attendre d'atteindre un niveau de perfection supérieur à 90 % revient à tuer la vitesse.
Cacher un code sous prétexte qu'il n'est pas parfait se traduira plus tard par un retravail encore plus important. L'équipe d'ingénierie de Shopify ne soumet pas de code parfait pour validation, mais publie des Draft PR (Pull Requests brouillons) pour valider l'orientation de son travail.
Mieux vaut maintenir la taille d'une PR sous la barre des 200 à 300 lignes. Ajouter un tag WIP avec la mention "Feedback souhaité uniquement sur l'orientation de la structure algorithmique" permet d'alléger la charge mentale des reviewers.
Le code initial n'est pas une œuvre d'art, mais simplement une hypothèse à vérifier. Dès réception du feedback, il suffit de l'intégrer rapidement et de passer à autre chose.
Une architecture virtuelle parfaite ne quittera jamais votre esprit. La seule ligne de code brouillon mais opérationnelle écrite aujourd'hui constituera votre véritable talent. C'est en abandonnant l'excuse du perfectionnisme que l'on parvient à s'extraire du bourbier du coût du retard.
