- Les développeurs seniors et les non-développeurs entendent la même phrase — selon laquelle les agents IA vont remplacer les développeurs — à travers deux critères différents : la stabilité et l’apprentissage du marché
- Les équipes métier veulent lancer vite pour obtenir du feedback et réduire l’incertitude, tandis que les développeurs seniors se méfient de l’augmentation de la complexité qui peut casser le système
- Une fois les clients acquis, deux boucles tournent en parallèle : l’exploration du marché et la continuité du service, et la responsabilité centrale du développeur senior devient la gestion de la complexité
- Pour convaincre, il ne suffit pas de dire que « la complexité est le problème » : il faut aussi répondre au besoin de vitesse de l’autre avec des expérimentations plus rapides, comme Google Forms ou un bouton ajouté à une interface existante
- L’IA accélère la mise en ligne, mais peut nuire à la compréhension, à la modification et au débogage du système, sans en assumer la responsabilité ; un développeur senior peut donc dissocier Speed et Scale
Pourquoi une même phrase est entendue selon des critères différents
- Les développeurs seniors et les non-développeurs interprètent différemment la même phrase : « les agents IA sont l’avenir du développement logiciel et les développeurs ne seront plus nécessaires »
- En copywriting, un message doit être adapté à son audience, et une même phrase prend donc un sens différent selon qui l’écoute
- Si l’intuition des développeurs seniors diverge de l’optimisme autour de l’IA, c’est parce que la définition du problème change selon que le travail se concentre sur l’apprentissage du marché ou sur la stabilité du service
Ce contre quoi les développeurs seniors se prémunissent
- Parmi les développeurs seniors, il existe un profil qui cherche à introduire quelque chose en s’appuyant sur de nouveaux outils, les pratiques d’autres entreprises ou les bonnes pratiques vues sur Hacker News
- Les développeurs seniors les plus appréciés commencent plutôt par demander : « En a-t-on vraiment besoin ? », « Que se passe-t-il si on ne le fait pas ? », « Peut-on tenir comme ça pour l’instant et y revenir plus tard si cela devient vraiment important ? »
- Ce profil cherche à éviter de développer autant que possible, à réduire et à réutiliser
- Dans le développement logiciel professionnel, ce que les développeurs seniors redoutent avant tout, c’est la complexité
- Les cas particuliers, les conditions, une nouvelle table de base de données ou un nouveau composant ajoutent tous de la complexité au système
- Les développeurs responsables d’un système en production finissent inévitablement par craindre l’augmentation de la complexité
- Même un développeur senior excellent en conception nouvelle et créative devient méfiant face à la complexité dès qu’il prend en charge un système en fonctionnement
Ce contre quoi les organisations métier se prémunissent
- Les marketeurs, commerciaux, chefs de produit et CEO évoluent dans une boucle où l’on met quelque chose sur le marché, on recueille du feedback, puis on apprend si cela a de la valeur
- Le but de cette boucle est l’apprentissage, et sa plus grande menace est l’incertitude
- Comme aucune stratégie ne garantit le succès, l’incertitude agit de façon brutale
- Quand les objectifs du marketing et des ventes, le salaire du fondateur ou les données du chef de produit se combinent avec la contrainte du temps, la seule manière de réduire l’incertitude avant l’échéance semble être de lancer sur le marché le plus vite possible
- Plus on met de choses sur le marché, plus on obtient de feedback, et plus on peut potentiellement réduire l’incertitude
- Toutes les entreprises commencent dans cette boucle, qui est mue par la vitesse à l’état pur
La deuxième boucle, une fois les clients acquis
- Quand les clients commencent à payer, une deuxième boucle apparaît, avec pour objectif la continuité et la garantie du service
- Le système doit continuer à fonctionner, rester compréhensible, débogable, modifiable, transmissible et stable
- Les développeurs seniors accordent de l’importance à la stabilité, car on leur confie la responsabilité métier de continuer à servir les clients
- Ce qui menace tout cela, une fois encore, c’est la complexité
- La complexité rend le système moins compréhensible, moins débogable, moins modifiable, moins facile à transmettre, et au final moins stable
- Quand la complexité augmente, la stabilité diminue, le développeur senior ne peut plus assumer sa responsabilité, et des problèmes comme l’arrêt des paiements peuvent survenir
- Si l’objectif de la première boucle est de réduire l’incertitude, celui de la deuxième est la gestion de la complexité
Là où la communication échoue
- Une fois les clients acquis, les deux boucles — exploration du marché et continuité du service — tournent en même temps
- L’entreprise doit explorer des possibilités tout en continuant à servir ses clients
- Selon la boucle à laquelle on consacre son temps, un même problème apparaît différemment
- Les équipes métier veulent construire plus vite et lancer plus tôt pour réduire l’incertitude
- Les développeurs seniors, eux, s’inquiètent de la complexité, des coûts de maintenance, de la compréhensibilité, de la vitesse de développement dans la durée et de la productivité au fil du temps
- Mais parler uniquement en termes de gestion de la complexité ne suffit pas à répondre au besoin de réduction de l’incertitude des autres équipes
- Pour convaincre, il faut aussi formuler la solution du développeur senior comme une réponse au problème de l’autre
- La communication échoue lorsqu’on exprime le problème du point de vue de la gestion de la complexité, sans savoir présenter la solution du point de vue de la réduction de l’incertitude
La véritable force pratique des développeurs seniors
- La compétence la plus utile des développeurs seniors consiste à éviter de construire l’inutile et à repérer les occasions de réutiliser ce qui existe déjà
- S’il faut collecter des données via un questionnaire, on peut utiliser Google Forms
- Au lieu de développer toute une nouvelle fonctionnalité pour la tester, on peut ajouter un bouton à l’interface existante et voir si les gens cliquent dessus
- Avant d’introduire un nouveau service d’analytics, on peut d’abord demander quelle est la décision la plus importante qui nécessite ces analyses, puis commencer avec une décision, un graphique, un indicateur
- C’est une approche qui consiste à planter une bougie sur un sandwich plutôt qu’à cuire tout le gâteau d’anniversaire
- Les développeurs seniors apprennent à utiliser des logiciels existants pour fournir ce que les gens veulent
- La formule courte pour exprimer cela est : « Can we try something quicker? »
- Le mot « quicker » reconnaît la vitesse que l’autre recherche réellement
- Le mot « something » suggère qu’il existe une autre manière d’atteindre le même objectif
- Le mot « try » porte l’idée que quelque chose d’imparfait peut néanmoins être suffisamment bon
- Cette phrase reconnaît le rythme de réduction de l’incertitude recherché par l’entreprise, tout en laissant au développeur senior la possibilité d’exercer son expertise : réduire, réutiliser et, si possible, éviter
La pression que l’IA change, et la responsabilité qui reste
- Comme l’IA permet de produire beaucoup de choses en peu de temps, l’attitude qui consiste à réduire, réutiliser et éviter peut sembler perdre son sens
- Mais l’IA n’est toujours pas capable d’assumer l’une des tâches du développeur senior : prendre la responsabilité
- Si les développeurs seniors tiennent tant à la compréhensibilité du système, c’est parce qu’ils doivent pouvoir le corriger quand un problème survient
- La compréhensibilité permet aussi de faire évoluer intelligemment le système à mesure qu’il grandit, et de continuer à fournir un service stable à des clients payants
- L’IA augmente fortement la vitesse de mise sur le marché, mais elle affecte aussi la boucle de stabilité dont le développeur senior a la charge
- Si des agents IA, des développeurs juniors, des non-développeurs, des investisseurs et leur entourage ajoutent tous du code au système, celui-ci risque de récompenser excessivement la vitesse au détriment de la stabilité
- L’IA peut dégrader la compréhensibilité, la modifiabilité, la capacité de débogage, la transmissibilité et la capacité à offrir des garanties
- L’IA peut rendre un système instable, mais elle n’en assume pas la responsabilité
- C’est là le cœur de l’inquiétude des développeurs seniors
Le développeur senior, plus proche de l’éditeur que de l’auteur
- Une méthode à la disposition des développeurs seniors est le découplage (decoupling)
- Pendant longtemps, seuls les développeurs logiciels pouvaient créer des logiciels ; ils étaient donc responsables à la fois de l’apprentissage du marché et de la stabilité du service
- Un même système portait simultanément ces deux objectifs
- Si l’on attribue un système différent à chacun de ces objectifs, on peut séparer la vitesse et la stabilité
- Cela ressemble au processus d’édition d’un romancier qui rédige d’abord rapidement un premier jet, puis garde ce qui fonctionne et élimine ce qui ne fonctionne pas
- Le travail de l’éditeur consiste à prendre les morceaux qui marchent et à les assembler en un tout cohérent
- La version Speed est un système pensé pour la vitesse, un espace où des agents IA, du code généré non revu, des développeurs juniors ou le marketing peuvent concrétiser rapidement des idées
- La version Speed ne vise pas la compréhensibilité, mais un état simplement assez bon pour obtenir un feedback du marché
- La version Scale est un système pensé pour la stabilité, conçu par les développeurs seniors pour être stable, compréhensible et extensible
- La version Speed permet à l’entreprise de continuer à apprendre sur le marché, tandis que les développeurs seniors construisent ensuite un système bien revu et compréhensible
- La conception de la version Scale est influencée par ce qui a bien ou mal fonctionné dans la version Speed
- Les fonctionnalités naissent dans Speed, puis sont stabilisées dans Scale
- La forme concrète de mise en œuvre peut rester floue, mais l’essentiel est de séparer explicitement le travail qui recherche la vitesse de celui qui recherche la stabilité
- Face à une demande ambitieuse, on peut dire : « La version Speed sera prête en 3 jours, et la version Scale dans environ 6 semaines »
- L’interlocuteur obtient ainsi la vitesse et l’élan, tandis que le développeur senior gagne du temps pour observer et concevoir
- Vu sous cet angle, un développeur senior peut se rapprocher davantage d’un éditeur logiciel senior que d’un « rédacteur logiciel senior »
1 commentaires
Commentaires sur Hacker News
La partie la plus importante de l’expertise vient du modèle du monde interne, et elle en est indissociable
En général, on croit que tout peut être exprimé verbalement et que, dès lors que les mots sont transmis, l’auditeur comprend exactement ce que voulait dire celui qui parle ; c’est cette croyance qui fait naître l’exigence de « transmettre » l’expertise d’un développeur à quelqu’un d’autre
En réalité, les connaissances se transmettent assez bien par les mots, mais ce n’est pas le cas de ce modèle du monde solidifié par l’interconnexion de tous les savoirs. L’IA peut connaître bien plus de faits, sans pour autant savoir encore utiliser ces connaissances d’une façon qui produise des intuitions étonnamment justes aussi souvent
En pratique, la transmission de l’expertise ressemble davantage à des indications sur où aller et quoi apprendre, et la personne qui les reçoit doit acquérir cette même expertise par ses propres efforts d’intériorisation et grâce à des projets appropriés
On distingue ceux qui comprennent et appliquent les « lois de la physique » du logiciel de ceux qui se contentent d’aligner des procédures sans chercher à comprendre la nature de chaque étape
Cela se voit particulièrement quand on enseigne la programmation fonctionnelle à quelqu’un d’habitué à l’orienté objet : chez certains, le modèle s’effondre, tandis que d’autres voient très vite qu’on peut relativement facilement traduire le monde des variables vers celui des monades
J’ai travaillé presque 30 ans, principalement dans une grande entreprise, et je passe chaque semaine un temps considérable à répondre aux problèmes des nouveaux arrivants. Rien qu’en entendant leurs questions, il m’arrive souvent de voir immédiatement que la racine du problème est que leur modèle du monde, la Theory dont parle Naur, est incomplet ou déformé, ce qui rend le raisonnement difficile
La tâche consiste à convertir sa propre théorie en représentations symboliques comme du texte ou des diagrammes, de façon à amener quelqu’un d’assez expérimenté et intelligent à se construire un modèle mental similaire. Autrement dit, on voudrait installer sa théorie dans la tête de quelqu’un d’autre
Le type de théorie dont parle Naur ne peut pas être transplanté directement, mais je pense que le travail d’un développeur senior, que ce soit en salle de cours ou sur le terrain, consiste à mobiliser l’expérience pour trouver comment reproduire ce genre de théorie. C’est pour cela que les compétences en communication sont importantes, et qu’il faut avoir vécu plusieurs fois le processus consistant à recevoir une théorie opérante d’une autre personne pour développer des instincts efficaces
C’est devenu aujourd’hui la partie la plus gratifiante de mon travail, et tant que j’ai le sentiment d’exercer utilement cette fonction, je ne suis pas pressé de prendre ma retraite
Quand je forme et accompagne des juniors, j’essaie de leur montrer ce qui est possible et les schémas qui mènent à l’échec, mais cette formation reste en général fragmentaire et incomplète
J’essaie autant que possible d’expliquer pourquoi on fait les choses ainsi, mais il y a peu de choses que j’interdis de manière catégorique. Je suis souvent surpris par la façon dont les personnes que j’ai formées résolvent les problèmes, et j’apprends souvent moi aussi
La formation fonctionne moins bien avec les personnes qui ne s’intéressent pas à leur propre contribution et ne voient le travail que comme un moyen d’être payées. Cela ne veut pas dire qu’elles ont tort de penser ainsi, mais si l’on construit sa vision du travail sur l’indifférence, il devient difficile d’intérioriser la formation
https://andymatuschak.org/books/
En tant que développeur senior, je déteste vraiment les affirmations globales
J’ai vu autant d’échecs dus à des attitudes du type « Est-ce vraiment nécessaire ? », « Que se passe-t-il si on ne le fait pas ? », « Peut-on tenir comme ça et y revenir plus tard si cela devient plus important ? » que d’échecs causés par des expérimentateurs
Chaque système est différent, chaque produit est différent. Si vous développez le firmware d’un scanner CT, votre façon d’aborder les nouveautés ne doit pas être la même que pour un CRUD SaaS avec 100 clients
Il existe clairement des seniors enthousiastes et trop ouverts qui coincent le système dans des impasses difficiles à quitter, mais il y a aussi des gens qui disent que PHP5 suffit largement
Un bon senior doit savoir reconnaître ces moments-là
Du coup, cela devient « il faut écouter le vice-président et utiliser Elasticsearch » quand on prend des décisions techniques
Bien sûr qu’il y a des moments où il faut agir, mais aujourd’hui l’équilibre penche trop vers le fait de compliquer tout plus que nécessaire
Cela ne veut pas dire qu’il ne faut pas créer de nouveaux produits et services, mais qu’il faut chercher, quand on le fait, le chemin de moindre entropie globale. Cela s’applique aussi à l’exploitation et à la réduction de la dette technique
L’optimisation prématurée est la racine de tous les maux
Selon qu’il s’agit d’une startup ou d’une grande entreprise déjà solide en trésorerie, le jugement à porter sur un changement de fonctionnalité cœur de produit sera différent
J’ai lu le texte avec plaisir, et je suis d’accord avec son message principal : mieux communiquer en fonction de son interlocuteur
En revanche, le cadrage donne l’impression de partir dans la bonne direction avant de bifurquer légèrement
Les deux boucles présentées gagnent à être aussi serrées et rapides que possible. L’une permet d’amener rapidement un système vers un point d’équilibre « stable » et maintenable, l’autre sert à traiter l’incertitude
L’idée supplémentaire de découper les systèmes pour mieux s’adapter à l’IA est aussi une intuition que j’expliquais déjà avec des spikes bien avant que l’IA ne devienne dominante
J’ai découvert que ma volonté de communiquer et de partager mon expertise ne rencontre généralement aucune demande de la part des développeurs juniors
Dans l’ensemble, les développeurs ne cherchent pas de mentor. Ils ne regardent même pas les profils LinkedIn et ne me voient pas comme une source possible de savoir et d’expertise
Ce n’est pas qu’après 30 ans de métier je n’aie rien à partager, c’est qu’il n’y a personne avec qui le partager
Un développeur peu expérimenté a proposé de remplacer un validateur d’URL par de la magie IA, et je m’y suis opposé en proposant à la place une solution de fuzzy matching basée sur un cache prérempli par IA, mais personne n’en a eu quoi que ce soit à faire. Maintenant, le modèle d’IA est tombé subitement, et le système est cassé. Il faut revalider tout le système
Un jeune développeur promu avant moi a commencé à rédiger un document sur la façon de corriger cela, puis a dit : « Dan, tu peux m’aider là-dessus ? » Il a été promu parce que, chez nous, avancer signifie rédiger des documents et faire des réunions plutôt que travailler de manière rationnelle, et maintenant il veut utiliser mon travail pour démontrer son leadership
Plus je propose de meilleures solutions, plus cela devient menaçant pour les développeurs moins expérimentés, et comme ça fonctionne plus ou moins, les managers ne s’en soucient pas. J’aurais peut-être pu mieux gérer la situation, mais me battre contre des absurdités m’épuise, et je veux juste écrire du bon code
À l’inverse, les juniors avaient envie de discuter, de déjeuner ensemble et de partager ce qu’ils faisaient. Les seniors restaient sur la défensive et seuls
C’est peut-être juste comme ça dans notre entreprise, mais le bureau est important
Certains développeurs seniors là-bas se mettaient en colère quand un junior leur posait une question. Il fallait déjà du courage pour demander quelque chose à quelqu’un qui avait 20 ans d’expérience, et il y avait une chance sur deux qu’il réagisse méchamment
Cela a été une bonne expérience d’apprentissage, et aujourd’hui je m’efforce délibérément de faire du mentorat
J’ai fait du mentorat de manière intermittente au cours des dernières décennies et j’ai eu la chance de rencontrer d’excellents mentorés. J’en ai vu certains évoluer pendant près de dix ans, et ils s’en sortent très bien aujourd’hui
Je n’ai rien de plus utile à dire sur la manière de les trouver, mais ces personnes existent
Mais juste après mon arrivée, il a annoncé sa démission en disant qu’il avait trouvé son remplaçant, et au final cela ne s’est pas bien passé pour moi
La plupart des proof of concept que j’ai vus sont devenus de la production dès qu’ils ont commencé à gagner en traction
Plusieurs fois, tout le monde a promis que « si ça décolle, on réécrira proprement depuis le début », mais cela n’est jamais arrivé
Le texte touche à la responsabilité et à l’accountability, mais pour ceux qui prennent les risques, cela n’existe pas. Ils expédient des idées folles aussi vite que possible, espèrent que les clients mordent, et en tirent un bénéfice. Comment faire marcher, faire évoluer et opérer cela sans que le coût d’exploitation dépasse le prix de vente, ce n’est pas leur problème
Certaines entreprises ont poussé la boucle de droite à l’extrême, et deux d’entre elles sont très connues aujourd’hui. Elles lancent quelque chose rapidement, ne scalent que de manière linéaire, puis vont lever de l’argent. Ce sont des entreprises « à succès », avec d’innombrables utilisateurs, dont certains paient. Tout développeur senior ou toute personne raisonnable qui demande « est-ce soutenable, quelle est la porte de sortie ? » se fait licencier, et il ne reste que des croyants
Quand les ingénieurs se contentent d’obéir docilement à des parties prenantes non techniques, cela crée un vide de responsabilité, et un jour tout explose comme une catastrophe majeure, puis on accuse la personne la moins capable de se défendre
À l’inverse, si l’on prend suffisamment de recul et que l’on pose assez de fois la question du « pourquoi », on peut résoudre presque n’importe quel problème métier d’une façon raisonnable sans pousser le système dans un horrible cul-de-sac à sens unique
Tous les environnements ne donnent pas ce pouvoir à l’ingénierie, mais ceux qui ne le donnent pas n’arrivent pas à retenir les seniors qui veulent voir leur jugement respecté. Parfois, la dette technique est le bon choix pour le business, mais un ingénieur suffisamment senior peut toujours prévoir une porte de sortie
En revanche, on ne peut pas placer la pureté du système au-dessus du problème métier. C’est le business qui paie le coût du système, et l’oublier revient aussi à perdre la base de son influence
La conclusion du texte revient en fait à ce vieux conseil : « construisez-en un en prévoyant de le jeter ». J’ai moi aussi lu The Mythical Man-Month, mais la vraie question est : comment convaincre ceux qui prennent les décisions
Si le résultat n’était pas à la hauteur des attentes, on désactivait ou supprimait la fonctionnalité ; sinon, elle était revue puis correctement refactorée
L’équipe disposait d’une forte autonomie et il y avait très peu de plaintes sur les délais, principalement parce que les autres départements étaient le plus souvent en retard. Seul le marketing avait toujours des « idées »
Le fait que ce soit un prototype ou un proof of concept n’a fondamentalement pas d’importance si l’on n’est pas capable d’énumérer les vrais problèmes que cela pose
Beaucoup d’équipes se plaignent d’être noyées sous la dette technique, que c’est un gros risque et que cela les ralentit, mais les journaux d’incident ne montrent pas beaucoup d’événements, rien n’indique que ce soit dû à du code dangereux en production, et il n’y a pas non plus dans les registres de risques une entrée du type « ce code est ancien, médiocre et dépend de composants en fin de support ». Aucune équipe n’arrive non plus à expliquer comment et dans quelle mesure la dette technique les ralentit
À l’inverse, j’ai aussi vu des équipes passer des mois à refactorer avant une sortie sous prétexte de rendre l’application qu’elles avaient écrite « meilleure ». Toute livraison de valeur a été retardée, le leadership s’est évidemment mis en colère, et il ne restait presque plus de confiance
Il faut de bonnes discussions entre l’équipe et les parties prenantes sur ce que signifie livrer, pour que tout le monde puisse être satisfait ; mais en leur absence, les parties prenantes gagnent toujours
Le texte passe à côté du problème fondamental des incitations. Ce que veut « l’entreprise » n’a pas d’importance ; ce qui compte, c’est ce que veulent les personnes qui prennent une décision donnée
Il y a des gens dont l’emploi est assuré tant qu’ils lancent une nouvelle fonctionnalité ou une nouvelle application qui se voit quelque part dans les métriques de l’entreprise. Même si un développeur senior dit que c’est une mauvaise idée, ces gens-là n’écoutent pas ou s’en moquent, parce que leur propre poste est en jeu
Mais côté produit, il faut aligner les fonctionnalités sur les besoins des clients ; il faut donc dire au chercheur d’arrêter de pousser dans cette direction
Les seniors vraiment compétents comprennent quelle est la culture dominante de leur entreprise actuelle et ce dont elle aura besoin dans cinq ans, puis ils s’y adaptent
Une startup de 5 personnes n’a peut-être pas besoin d’une complexité supplémentaire qui réduit sa runway. Une entreprise de 500 personnes peut au contraire avoir besoin de cette complexité pour atténuer les effets de second ordre de chaque décision métier
Ce n’est pas une logique binaire du type « évitez toujours la complexité », mais plutôt « ajoutez de la complexité quand cela a du sens », et même cette question devient très subtile quand l’entreprise doit survivre quelques mois de plus
S’il reste deux heures avant que la tempête n’arrive, on ne se demande plus quelle architecture concevoir, mais plutôt « est-ce qu’il va y avoir tellement d’eau qu’on ne pourra plus l’évacuer ? »
Le problème que je vois, c’est que la direction cache combien d’argent il reste réellement et à quoi ressemble le vrai calendrier, et joue un jeu de façade. Elle a peur que les contributeurs partent avant les moments critiques ; du coup, les gens continuent à prendre des décisions absurdes dans ce contexte et finissent tous par chercher un nouvel emploi
J’essayais depuis quelques jours d’exprimer presque exactement le même sentiment à mon équipe, jusqu’à la phrase « faut-il vraiment construire et tester toute une nouvelle fonctionnalité ? Est-ce qu’on a simplement ajouté un bouton à l’UI existante pour voir si les gens cliquent dessus ? »
On dirait que les ingénieurs souffrent collectivement depuis que l’équipe produit a décidé qu’elle n’avait plus besoin d’utiliser ses facultés mentales. Il faudrait d’abord construire, puis découvrir plus tard — ou jamais — les personas utilisateur et l’utilité réelle
Avant, on passait du temps à comprendre le domaine, les utilisateurs et la place du produit dans leurs processus ; maintenant, on lance simplement ce que l’on imagine que des utilisateurs fictifs pourraient vouloir, puis on expérimente jusqu’à ce que ça marche
Cela produit exactement le problème décrit dans le texte original. Chaque fonctionnalité arbitraire fabriquée en vibe coding devient une source d’instabilité et de risque, et comme personne n’a de modèle mental opérant de cet objet, on ne peut plus la maintenir qu’avec encore plus de vibe coding
Même si l’on pouvait réduire la complexité à une seule dimension de mesure, ce ne serait qu’un élément parmi d’autres dans l’espace des solutions
Il existe d’autres propriétés comme la maintenabilité, la scalabilité, la fiabilité, la résilience, l’antifragilité, l’extensibilité, la généricité, la durabilité ou encore la composabilité, et elles ne s’appliquent pas toutes en permanence
À mon avis, la capacité à parler non pas en termes d’une dimension unique, mais de compromis dans l’espace des solutions, est ce qui distingue un senior d’un Staff+
En revanche, si on l’entend comme ce qui rendra le développement de ce système plus simple et plus rapide sur les dix prochaines années-personnes, alors cela signifie choisir de contourner latéralement ce qu’une approche naïve voudrait attaquer de front
Comme dans la fable du lièvre et de la tortue, il est difficile de percevoir la dynamique où l’on brûle les deux premières semaines à toute vitesse pour décrocher les fruits les plus bas, des résultats visibles et un MVP, puis où la vitesse diminue sans cesse à cause d’une conception immature et de la maintenance pendant le développement. Cela a semblé « rapide » pendant quelques semaines, puis au final le planning a dérivé de six mois
En tant que programmeur, on finit forcément par comprendre que chaque dimension possible d’une conception est un compromis