Procédés Heuristiques et Certitudes

Nos procédés heuristiques, tout ce que nous trouvons dans nos livres, nos blogs et nos videos, dans nos conversations, ceux que nous essayés une fois ou deux comme ceux que nous utilisons depuis des années avec succès ; tous ces procédés sont aussi fiables et sûrs que peut l’être un procédé heuristique : une approche supposée produire dans les meilleurs délais la réponse à un problème donné, possiblement contredite par d’autres approches, et sans garantie de résultat.

Le Problème des Heuristiques

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.

Summing numbers with AI

Vous avez dit :

can you sum integer numbers for me

ChatGPT :

Yes, I can help with that! Just provide me with the integer numbers you’d like to sum, and I’ll do the calculation for you.

Améliorer un système sans le stabiliser

vers le 12/11/24 :

Vous ne pouvez pas améliorer un système sans d’abord le stabiliser. Pour le stabiliser, il faut s’intéresser à ses régulateurs. […]

Un système instable ça s’écroule, implose, s’enraye en quelques jours voire quelques heures et on n’en parle plus.

Embardées

Une équipe crée un produit logiciel : il lui faut donc le tester. Sinon elle y laisse des plumes. Des défauts résiduels, qui provoquent plantages, pertes de temps, mécontentement, perte de confiance.

The Count to 3 Principle

Paradoxically, one way to master the power of a tool is to probe its weaknesses. Thus, we offer the Count-to-Three Principle:

Session du Dojo de Développement du 22/11/2024

Session du Dojo de Développement du 22/11/2024

Sujet retenu : Démo (i.e. une persone présente une session de code, en répondant aux questions et en empruntant éventuellement les directions suggérées).
Langage : assembleur 6502.
Sujet : dessiner une mosaïque de pixels

Améliorer avant de Stabiliser

Vous ne pouvez pas améliorer un système sans d’abord le stabiliser. Pour le stabiliser, il faut s’intéresser à ses régulateurs.

Rôle Comme Régulateur

Réunion express entre 2 réunions, Xavier (CTO) et Victor (CEO) à propos du plan de livraison du lot 44.7

Rôles Croisés

Fin de la réunion backlog. Tous ont quitté la visio-conférence, sauf Jérémie (Tech Lead) et Marion (l’une des 3 POs) qui lui a demandé de rester.

Nouveaux Régulateurs

09h10 Xavier (CTO) et Jérémie (Tech Lead) font un point rapide avant que la journée ne prenne feu.

Bruit Dans le Signal

19h14. Térence (Dev junior) et Jérémie (Tech Lead) terminent au calme une session de Pair Programming. La tâche est suffisamment simple et sans accroc pour laisser la conversation cheminer un peu.

Des Problèmes Nouveaux

Histoire courte, au dénouement brutal :

Une équipe Tech, à la demande et avec l’appui du CTO, décide de consacrer un (petit) extra de budget à améliorer sa stratégie de prévention des défauts, en se mettant à écrire systématiquement des vérifications automatisées.

Premier Sprint de Vérifs Auto

from: Jérémie █████
to: Xavier ██████

subject: 1er sprint de verifs auto

Proposition de Changement

Conférence dans l’open space/café/cuisine/détente. Y participent : Alex, Olivia, Karim, Théo, Ibanèz, Yasmina, Jean, Oleg, Térence (développeurs), Xavier (CTO), Jérémie (Tech Lead), Clara (Responsable des Tests).

Xavier vient de “mettre sur la table” un changement de processus, dans lequel le code de chaque user story que l’équipe délivre serait gardé par des vérifications automatisées, au niveau “unitaire” et/ou “intégration”. C’est le temps des Questions/Réponses.

Top Management

Xavier, CTO d’une entreprise qui écrit du code qu’elle n’a pas le temps de vérifier, fait le point avec Victor, son CEO.

Modèles Mentaux

Le conflit (cf posts précédents) entre Clara et Jérémie à propos des tests constitue un évènement. Les évènements s’inscrivent dans des trames, lesquelles suivent plus ou moins fidèlement la voie des processus et de la culture de l’entreprise.

Avalanche, Érosion

Résumé des épisodes précédents : Xavier est de CTO d’une entreprise qui produit du code plus rapidement qu’elle n’arrive à le vérifier. Après avoir assisté au débat qui oppose Clara, la Responsable des Tests, à Jérémie le Technical Lead, il fait le point avec ce dernier.

Conflit Test/Dev

Vers l’époque où le terme “software engineering” a été inventé, cette blague circulait :

À une assemblée de consultants spécialisés dans le développement de logiciel, un journaliste demande : à main levée, qui d’entre vous accepterait de monter à bord d’un avion dont le pilote est un programme ?

Test et Bruit

Clara teste le produit : son objectif est d’y rechercher des problèmes. Là où TDD et la relecture sont appliquées routinièrement, son activité à elle requiert au contraire une attention sporadique, ou thématique, puisqu’elle ne peut pas “couvrir” l’ensemble, immense, des comportements possibles. Parfois, un simple “bruit” guide son intuition.

Vérifications Automatisées

Dans mes posts sur TDD, j’utilise le terme “vérification automatisée” plutôt que “test”, pourquoi ?

Triangulate

En continuant d’explorer la conception vue comme un processus régulé par des correcteurs de “bruit”, on trouve un pattern TDD souvent utilisé en conjonction avec Fake It :

Triangulate

Fake It Til You Make It

Pour approfondir encore la notion de bruit dans un processus de conception vu comme un système muni de régulateurs, voici un pattern qui choque souvent ceux qui découvrent TDD :

Fake It (‘Til You Make It)

Relecture de Code

Des vérifications automatisées ne sont pas l’unique moyen de corriger le bruit qui est présent dans la conception de votre produit.

Provoquer volontairement le bruit

Dans mon post d’hier, je considére la pratique de TDD comme “création d’un sous-système de correction du bruit dans un système qui articule un flot de conception”. Ouf. Si vous n’avez pas l’histoire, je vous recommande de passer par le post d’hier.

Pourquoi Écrire des Vérifications Automatisées ?

Pourquoi écrire des vérifications automatisées ?

Parce que votre modèle du comportement détaillé du système tel que vous le programmez comporte du bruit, et que vous voulez corriger ce bruit. La plupart de ces vérifications s’exécuteront sans échec : vous les programmez en même temps que le code qu’elles vérifient. Un peu comme des garde-fous qu’on a posé là sur cette passerelle, alors même qu’aucun accident n’est jamais arrivé.

Chantier de Refacto

On va lancer un chantier de refacto qui devrait nous prendre environ 3 semaines. Avez vous des conseils ?

6 Machines Simples

Aujourd’hui je vous dévoile mes 6 machines simples, que j’utilise pour écrire du logiciel, seul ou en équipe. Si on comparait le développement à de la mécanique (une comparaison acrobatique 😅 ) quelles seraient mes machines simples ?

Les Mauvaises Chaussures

Que pouvons-nous faire lorsque notre équipe se trouve dans un conflit ?

Nous pourrions ne rien faire, et voir ce qui se passe. Wait and Assess (Don’t look up). Il va se passer quelque chose rapidement.

Une Équipe Idéale

Imaginons une équipe idéale, composée de personnes compétentes et motivées, raisonnables, patientes, curieuses, et enthousiastes à l’idée de réaliser ce projet malgré tous les obstacles. Ses processus de décisions sont ritualisés et transparents (par ex: ADR, Wardley Maps, Story Mapping, Sprint Review, Tests, Analyse…).

Conflits d'Idées

Au sein d’une équipe qui réalise du logiciel, il est indispensable d’avoir des conflits d’idées, car cette équipe cherche activement la meilleure solution (réalisable dans les meilleurs délais, étant donné l’information dont elle dispose et les incertitudes qui cernent son projet) et il est très rare qu’une solution consiste en la réunion de toutes les idées du groupe sagement combinées dans un pur esprit de consensus. Une équipe qui est en sécurité – donc où chacun peut être vulnérable, c’est à dire ouvert – peut exposer, étayer et résoudre 10 conflits d’idées par semaine et s’en trouver parfaitement indemne de toute meurtrissure, voire même enthousiaste pour son projet, qui avance.

Déplacement de Conflit

En cas de conflit dans notre vie personnelle, l’attitude recommandée consiste à prendre son courage à deux mains (et sa lucidité) et tenter de résoudre le conflit du mieux que nous pouvons.

Pour une entreprise, les options sont plus nombreuses, et bien moins claires. Il arrive fréquemment qu’une organisation déplace les conflits au lieu de les résoudre.

Évitement de Conflit

Résumé : un éditeur de logiciel florissant, face à une décision :

• céder rapidement et définitivement des parts de marchés à la concurrence en ratant la révolution technologique du jour,
• ou bien investir dans un projet pharamineux de refonte de son produit star

Dans les couloirs de l’entreprise, on envisage ce problème à travers différent prismes.

En présence d'un conflit

En présence d’un conflit, nous ne prenons que très rarement l’initiative de tenter de le résoudre. Nous commençons plus souvent par nous en détacher. Si nous attendons (un peu) est-ce que le conflit ne va pas disparaître lui-même ? Il y a beaucoup à redouter et à détester dans les conflits :

• ils mobilisent de l’énergie, du temps, du courage et de la patience
• ils déclenchent souvent des comportements d’aggression et de défense (et alors nous ne donnons plus le meilleur de nous-mêmes)
• ils deviennent rapidement urgents, ce qui nous pousse à opter pour des solutions à la fois simples, radicales, et fausses

Qu'est-ce que l'état de l'art d'un projet ?

Qu’est-ce qu’on entend par l’état de l’art d’un projet ?

État de l’art : l’ensemble des procédés qu’une personne ou un groupe, (une équipe, une organisation, la société…) utilise à un moment donné afin de produire la meilleure solution possible face à un problème imparfaitement compris, dans une situation incertaine, à l’aide de ressources limitées.

Pourquoi apprendre en permanence ?

Je rebondis sur un post récent de Rudy Onfroy (merci Rudy!)

Pourquoi, lorsqu’on est développeur, devrait-on apprendre en permanence ?

Comment savons-nous ce que nous savons ?

Quand nous faisons évoluer le code d’un système, comment savons-nous ce que nous savons ?

Qu'est-ce qui survit lorsque le dernier DEV a quitté l'équipe ?

Qu’est-ce qui survit lorsque le dernier “dev” a quitté l’équipe ?

Le code, bien sûr. Dans certaines organisations, c’est tout ce qui compte. Elles disent : “Nous avons le code, inutile de réinvestir dans la conception. Il suffit de refondre”.

Peur de changer le code

Souvent ce qui domine une équipe de développement, c’est la peur de changer le code.

Et avec raison. Ceux qui n’ont pas peur, c’est qu’ils manquent d’expérience.

Miracle IA

Dans les campagnes de sensibilisation sur l’IA miraculeuse qui divise les coûts par mille en remplaçant les développeurs on retrouve ce mythe du développeur vouté sous un carcan de tâches inessentielles : traduire du matériau déjà pensé en code exécutable.

Effets Démo LI

Je lis un post sur Linked In à propos d’un évènement passé et qui commence par : “Vendredi dernier…” ou “La semaine dernière”, “Ce samedi 8 juin fut l’occasion…”. Chouette ! J’ai envie de lire.

Effets Démo IA

ToF: trouve moi un adjectif en français qui commence par y

chatGPT : Un adjectif en français qui commence par “y” est “youthful” (jeune, juvénile).

Linked IN : ✦ Rewrite with AI

Publié sur Linked In le 14/04/2024

Effets Démo

🚫❗️💔
— Et bien sûr on a eu l’effet démo : au lieu d’afficher la pièce, bam ! Page blanche. C’était l’angoisse. Le client n’a rien dit. Le CTO nous a demandé si on avait des tests auto sur cette partie du soft.
— Des tests autos, comme il y va. Et puis quoi encore ?

Tester c'est vérifier

“La plupart des équipes QA disparaîtraient si chaque équipe avait une stratégie de test adéquate. Repasser l’activité de test à une autre équipe c’est faire preuve d’un manque de responsabilité.” (Expert TDD)

User Story = Document

“Une fois le besoin recueilli et précisé, le Product Owner va se réunir avec son équipe produit (ex : UX designer, architecte, lead développeur…) pour réfléchir à des pistes de résolutions de ce besoin en fonction des possibilités techniques.

Développer, c'est créer un produit

“Pas seulement l’adaptation aux changements, mais aussi l’ajout constant de valeur.” (Manifeste des artisans du logiciel)

Programmer, c'est écrire du code

“Là on va entrer dans une période de crunch. Plus question de binômes. Une personne par story.” (Delivery Manager)

Simplifications

Sur les réseaux sociaux, l’information voyage à la vitesse de la lumière, mais la désinformation va tout aussi vite, c’est connu. Ce qui m’intrigue sur Linked In en particulier, c’est que la désinformation sur un sujet semble émaner principalement des acteurs professionnels concernés. J’en conclus que Linked In est plus un réseau centré sur la docu-publicité que sur l’information.

Bons crayons, mauvais crayons

Jean-Michel, CTO Dessinateur :

« Il y a les bons et les mauvais crayons de couleur. »

Dette Technique et Management

La dette technique, c’est un désalignement entre l’état de l’art de votre projet et ses objectifs et contraintes.

⇒ Pour résorber la dette technique, il faut réaligner l’état de l’art, les objectifs et les contraintes, donc réaligner la Tech, le Métier et le Management.

La qualité c'est…

La qualité, c’est de la valeur pour une personne.

⇒ Pour améliorer la qualité vous devez comprendre pour qui cette valeur compte.

Expérience

Comme d’habitude, le conseil de Rudy Onfroy, court, pratique, efficace, frappé au coin du bon sens et pourtant nécessaire rappel en ces temps où le Reach bouffe le bon sens au petit déjeuner tous les matins sur Linked In.

Dette Technique et Management

Dans votre agenda, la semaine est déjà pleine à craquer. La prochaine version de l’application ne sera pas livrée à la date annoncée. Deux de vos Tech Leads quittent l’entreprise : qui pour les remplacer ? Le dernier passage en prod a bien failli mal tourner. Certains choix techniques s’avèrent inadéquats : on commence même à parler de refonte…

Cohérence d'ensemble

— Regarde ce qu’ils nous ont encore fait ces idiots de développeurs… — Informe toi avant de juger. J’étais sur ce projet : on ne s’est pas fait faute de prévenir le Métier qu’installer un simple PoC en production était une très mauvaise idée, en vain.

Dette Technique en Euros ?

Managers : la chose la plus simple et la moins utile que vous puissiez faire avec la dette technique, c’est de commencer par vous faire donner son prix en euros. Même si les gens qui vous sortent un chiffre savaient de quoi ils parlent, c’est prendre la lorgnette par le mauvais bout.

Dette Technique et Management

Sur les réseaux sociaux, dans les meetups, il est de bon ton de critiquer le mauvais développeur, et de glorifier le développeur consciencieux, le “clean coder”. Le mauvais développeur arrête la mise au point dès que ça semble marcher. Le bon développeur écrit des tests et refactore son code, en bon artisan. Le mauvais développeur laisse un désordre derrière lui. Le bon développeur laisse le code plus propre qu’il ne l’a trouvé en arrivant.

IA remplacement/4

Les influenceurs sur Linked In : Si vous ne voyez pas que l’IA est la solution, c’est que vous faites partie du problème.

IA remplacement/3

Les influenceurs sur Linked In : on peut utiliser les IAs pour tester nos logiciels. Bienvenue dans la révolution.

Un testeur : écris une procédure de tests pour le programme fizzbuzz

IA remplacement/2

Les influenceurs sur Linked In : seuls ceux qui maîtrisent l’IA survivront. Les autres seront maîtrisés par l’IA.

Clean Coder, Saint Crafter

Je récuse le terme de code “clean”, “propre”, qui mène insidieusement mais sûrement au développeurs/es “clean”, qui mène doucement à la mystique des vertus morales du Saint Crafter.

IA remplacement/1

Les influenceurs sur Linked In :

Si vous ne prenez pas votre destin en main, l’IA va vous remplacer, et vous l’aurez bien mérité, parce que vous faites un travail d’exécutant.

Fondation ou Mercenaire ?

Pour une entreprise qui développe du logiciel, il y a deux extrêmes à éviter : (spécial clin d’œil Rudy Onfroy)

Thanks SoCraTes.FR

It’s over but my head is still buzzing with the many presentations, interactions, ideas, conversations and laughters that we had from Thursday through Sunday at the Socratesfr conference. I had the pleasure and honor to facilitate the opening World Café and the 2 days Open Space unconference.

A glimpse of some of the sessions I attended:

No Product

Beaucoup de développeurs considèrent l’option “No Code” comme une mauvaise idée. Disons, une idée qui va faire long feu. Cela se comprend, si l’on considère que pour le développeur l’écriture du code constitue son activité essentielle.

Préjugés

La plupart des gens se font une idée très simplifiée ce que c’est que développer du logciel :

⌨️ développer du logiciel, c’est écrire du code ⌨️

Cet archétype, au sein même de l’industrie du développement et du conseil, omniprésent. Exemples :

Rationalisations

Travaillant dans le contexte de projets de développment depuis 35 ans, j’ai croisé plusieurs “générations” de développeurs et de managers. Leurs positions à propos des tests varie d’une génération à l’autre, avec quelques constantes :

Rationalisations

Il n’y a pas assez de testeurs·es dans les entreprises qui développent du logiciel. Et lorsqu’il s’en trouve, le processus de l’entreprise rend leur travail inefficace.

Jeu Quiz

⚫️ Lorsque je passe mon smartphone sur la borne du portique pour présenter le QR code de mon ticket, le portique ne valide pas mon ticket. C’est parce que mon appareil est passé en mode “paiement”, et n’affiche plus le QR code.

Selon vous, qui serait le plus à même d’identifier ce problème ?

Défense vs Exploration (4)

— Ah ! Cette fois-ci on a à la fois les concepteurs, et les chasseurs de bugs.
— Oui. Appellons-les les “défenseurs” et les “explorateurs”.
— À lire cette carte on dirait que dans leurs activités respectives ils sont parfaitement isolés les uns des autres.

Défense vs Exploration (3)

— Ok, nouvelle carte. Où sont passés les chasseurs ?
— Ils ne font pas partie du dispositif. Pas de testeurs, pas de “QA”, ici.
— Et ces acteurs, à l’intérieur du périmètre en bleu, qu’est-ce qu’ils font ?
— De la conception.

Défense vs Exploration (2)

— Une nouvelle carte ! Avec cette fois des “acteurs” comme tu dis. Ils chassent les bugs ?
— Disons qu’ils recherchent activement des problèmes possibles avec l’application.
— À voir le nombre de triangles, ils ne vont pas rentrer bredouille…
— Oui, c’est un bon terrain de jeu.

Défense vs Exploration (1)

— Qu’est-ce que ça représente, cette carte ?
— Ça ? Les vestiges d’une application…
— Comprends pas.
— La ligne pointillée bleue délimite l’ensemble des comportements que l’application devait présenter une fois installée en production. L’équipe qui a conçu cette application, et l’a construite, s’est dit : elle n’ira pas plus loin, mais à tout le moins, elle fera ça, c’est à dire ce qui se trouve à l’intérieur de la ligne bleue.
— Et les triangles rouges ?
— Ce sont tous les comportements incorrects rencontrés par ceux qui ont utilisé l’application.
— Des bugs, donc.

Stratégies

Tests #2

J’allais détailler pourquoi je jette aux gémonies la pyramide des tests, et la couverture des tests avec elle, mais inutile : le dernier billet de Laurent Bossavit met en lumière le problème bien mieux que je ne l’aurais fait. Lisez-le !

Vous l’avez lu ?

Et si on parlait tests ?

Tests #1

Et si on parlait test ?

En commençant par un peu de vocabulaire. “Tester” : en voilà un mot chargé… On l’utilise pour désigner des choses très différentes. Comme tout le monde j’ai une tolérance raisonnable pour l’ambiguïté et je suis habitué à la polysémie des mots du français, mais dans le cas du mot “tester”, je ne peux m’empêcher d’y voir une source de confusion.

Diagrammes et Modèles 10

Systems #10

from: carla
to: martin
date: 2023-07-10
subject: diagrammes

Hello Martin,
Pour faire suite à ta demande, et avant mon départ en vacances, voici un récap de nos conversations.
En pièce jointe je t’ai fait une copie de quelques archétypes fréquents.\

Diagrammes et Modèles 9

Systems #9

Martin: Est-ce que je peux te parler franchement ?
Carla: Quelle drôle de question ! Bien sûr !
M: C’est bien gentil ces diagrammes, mais en quoi ça nous aide ?
C: …
M: Je veux dire, c’est très général, on n’apprend rien qu’on ne sache déjà, non ?

Diagrammes et Modèles 8

Systems #8

Carla: Martin, comment ça va ?
Martin: Un peu sous pression, mais OK. Au fait merci pour le diagramme d’hier. Je crois que ça nous a évité de faire une erreur.
C: Contente que ça te soit utile…
M: Bien sûr, le COMEX est toujours dans l’attente d’une solution pour le projet. Ils me demandent si on ne pourrait pas doubler les cadences et mettre le turbo.
C: “Doubler les cadences” ?

Diagrammes et Modèles 7

Systems #7

M: Tu as raison, ça ne marche pas.
C: Euh… Qu’est-ce qui ne marche pas ?
M: La stratégie trouvée en COMEX : on se sépare des mauvais.
C: Sans blague. C’était un 180 cette idée.

Diagrammes et Modèles 6

Systems #6

Martin : Bon j’ai parlé de ton idée en COMEX, figure-toi.
Carla : Mon idée ?
M: Oui, ton idée d’améliorer les performances en s’appuyant sur l’apprentissage.
C: Ah. Ce n’est pas exactement mon idée mais…
M: Peu importe : tout le monde est contre.

Diagrammes et Modèles 5

Systems #5

— C’est bien joli tes diagrammes, mais je ne suis pas plus avancé.
— Quand même, est-ce qu’on n’y voit pas au moins un peu plus clair ?
— Si, bien sûr. Mais je n’ai pas de solution…

Diagrammes et Modèles 4

Systems #4

— Si je comprends bien, on est pris dans étau.
— Qu’est-ce que tu veux dire ?
— Soit nous testons notre logiciel de bout en bout, et nous allongeons les délais de livraison, soit nous le livrons au plus tôt, mais alors nous devons traiter les incidents en production.

Diagrammes et Modèles 3

Systems #3

— Qu’est-ce que nous essayons de faire, au juste avec ces diagrammes ?
— Trouver des relations entre des variables à propos de ce que nous observons.
— Et quand on a trouvé ces relations, qu’est-ce qu’on a de plus ?
— On peut identifier des points d’interventions, c’est à dire changer ce que nous faisons de manière à changer ces relations.

Diagrammes et Modèles 2

Systems #2

— Où est-ce qu’on en était ?
— On a identifié 2 agrégats dans le système formé par ton équipe de développement, dénotés par 2 variables facile à observer, et même à dénombrer :

• les CHANGEMENTS apportés au logiciel
• les rapports d’INCIDENTS

Diagrammes et Modèles 1

Systems #1

— Bilan des courses, on est au sprint 15 et les choses ne vont pas mieux. Je dirais que par rapport au début de l’année on a 4 fois plus de bugs. 4 fois plus !
— …
— Si seulement on pouvait dénicher de meilleurs développeurs !

Apprentissage, Performance

Transmission #6

🏭 Chère entreprise,

Il faut se rendre à l’évidence : tu obtiens ce que tu demandes exactement, quoi que tu obtiennes.

Auto-Formation

Transmission #5

— Bon eh bien on a fait le tour. Bon courage tout le monde ! 👋
— Merci Jérémie, bon courage ! 👋
— Victor, est-ce qu’on peut se parler en privé si tu as 5 minutes ?
— OK.

Transmissions

Transmission #4

Il y a 4 jours se déroulait AlpesCraft, la conférence et non-conférence que je ne veux manquer sous aucun prétexte !

Où apprendre et s'améliorer ?

Transmission #3

Dans une entreprise qui manufacture des produits, pour peu qu’elle soit gérée dans une approche d’amélioration continue, l’amélioration se produit sur le lieu de travail, et non en dehors. Ses managers n’exigent pas des employé·es qu’ils ou elles améliorent leur travail le soir ou le week end, en pratiquant chez eux 5S, jidoka ou kaizen. 🧱

Bras de Mer et Bras-Cassés

Transmission #2

— Le projet a déroulé 4 sprints déjà, et ton n’équipe n’a pas gagné en vélocité. Qu’est-ce qui explique cela ?
— J’ai des bras-cassés.
— Intéressant… Ils sont tous arrivés ici, dans la boite d’abord, puis au 5ème étage, puis chez toi… 🙄
— Non, bien sûr. Mais tu vois ce que je veux dire…

Transmission

Transmission #1

L’équipe de Victor et Jérémie fait une relecture de code. La conversation s’engage entre Victor, et Tom qui a modifié le code.

Auto-Prescription

Standard #8

Merci Mauko pour ta contribution à cette conversation à propos du standard. La distinction que tu fais entre descriptif et génératif, complexe et simple, invite à considérer comment on peut parfois “altérer” un standard récemment acquis.

Foire Aux Questions

Standard #7

0️⃣ Quelle est la procédure standard pour améliorer notre standard ?

Recadrage

Standard #6

— Bon Victor, tu sais pourquoi on doit se parler aujourd’hui ?
— Si je ne me trompe pas, c’est à cause de la discussion de l’autre jour, après la démo… 🧱
— Discussion ? Ce n’est pas des discussions que vous avez toi et Jérémie, ce sont des batailles !

Plus Moins Intéressant

Standard #5

☕️🥐

— Alors comment ça c’est passé cette première démo avec ton équipe ?
— Bah ! À part le plantage au milieu de la partie la plus intéressante, tu veux dire ?

Quinconce

Standard #4

🧱

— Franchement, mettre les parpaings en quinconce, c’est une perte de temps, tu ne crois pas ?
— Mais non ! C’est prouvé ! Et même éprouvé !\

Commentaires

Standard #3

Thèse : Tout doit être standardisé. Il suffit de définir LA bonne manière pour chaque chose. De cette manière on évite les discussions et les conflits d’idées.

Antithèse : Rien ne doit être standardisé. Chacun fait selon ses critères et ses préférences. De cette manière on évite les discussions et les conflits d’idées.

Synthèse : Une équipe établit parallèlement au logiciel qu’elle développe, un état de l’art définissant la meilleure façon de faire étant donnés son contexte, ses objectifs et ses contraintes. Les discussions et conflits d’idées sont incontournables si elle veut améliorer cet état de l’art.

Sicob

Standard #2

— Bonjour ! On peut se tutoyer. C’est la DSIO qui t’envoie, c’est bien ça ?
— Oui. On m’a dit de me présenter à 9h.
— Parfait. Je pense que tu vas commencer par faire le tour de toutes les applications du service. La personne qui en avait la charge travaille désormais dans une de nos filiales américaines, mais elle a laissé quelques notes.
— Entendu.
— Bon, il faut que je te prévienne, c’est un peu le SICOB ici…

Revue et Standard

Standard #1

— Ça va Jérémie ?
— Tu tombes bien, Victor, prend une chaise, et regarde un peu ça. 🪑
— Quoi donc ?
— Je suis sur le code du module de vente. Franchement, le développeur qui a codé ça, j’aimerais bien le rencontrer…

Artisanat

Prevention #10

Dans un système en crise, on n’améliore pas, on réagit.

Rollers et Scooters

Prevention #9

— Midi dix : c’était rapide, pour une fois, ta rétro.
— Oui, 2 dévs sont en vacances, donc on a été un peu plus vite.

Patinette

Prevention #8

— Oui, on fait du Pair Programming, depuis au moins 2 mois, mais c’est épuisant.
— Qu’est-ce qui est épuisant dans le Pair Programming ?
— Parler de la conception, du code, à longueur de journée, 9h30 - 18h.
— Vous codez en binôme de 9h30 à 18h ?

Détrompeurs

Prevention #7

Dixit Shigeo Shingo :

Il y a 4 objectifs d’amélioration : plus facile, meilleur, plus rapide et moins cher. Ces 4 objectifs apparaissent dans l’ordre de priorité.

Cette maxime, a elle seule, devrait achever de convaincre les équipes qui travaillent en Lean d’adopter Pair Programming ou Ensemble Programming.

Couloirs

Prevention #6

Dans les entreprises la tolérance au désordre est inversement proportionnelle à la taille de l’organisation. Le désordre est un mal nécessaire pour la toute petite entreprise, qui favorise la résilience et la redondance contre la sécurité et la pérennité.

Breakpoints

Prevention #5

Episode 3 (cf Episode 2 par Laurent Bossavit)

🐌🛑🐢

— Victor ! Ticket 915 : ça te dit ? 🪑
— Yes ! Débugguer, ça me familiarise avec la base de code.

Le Standard

Prevention #4

— Salut, moi c’est Victor.
— Bonjour Victor ! Moi c’est Jérémie. Je t’en prie, prend la chaise qui est là. 🪑
— Merci.
— Donc si je comprends bien tu viens d’arriver, ç’est ça ?
— C’est ça. Et Gauthier m’a indiqué…

Double Boucle

Prevention #3

C’est peut être une variante de l’Erreur Fondamentale d’Attribution, qui consiste à juger comme incompétentes des personnes raisonnablement expérimentées et bien disposées mais qui se trouvent aux prises avec un système médiocre.

Moi même, je me dis souvent : Ces deux préhistos ont dû se donner un mal fou pour se fabriquer des roues carrées, les idiots.

Provisions

Prevention #2

Lorsque j’ai découvert et intégré TDD à mon travail, je disais à qui voulait l’entendre que c’est un moyen efficace et motivant de produire du code propre et qui marche. Et ceux qui voulaient l’entendre de répondre aussitôt :

— Oui, mais :

Quizz

Prevention #1

🏢 Le lieu : entreprise ARGH (Automated Resource for Global HR)

📅 La date : déploiement plus 1 an, 3 mois et 17 jours

👥👥 Acteurs présents : Arthur (Tech), Bénédicte (Tech), Carla (Métier), David (Management)

▶️

Résolution

Regulation #10

🌆 Dimanche, vers 19h :

— Bon eh ben le serveur tourne à nouveau.
— En tout on a été HS… 2 heures 24 minutes.
— Ce qu’il faudrait, c’est revoir ce programme. C’est la troisième fois en 6 mois !
— Ecoute, repose toi bien, et on en reparle plus tard. Demain il fera jour.

Mon Indicateur de Productivité

Regulation #9

Ma première rencontre avec la productivité a eu lieu en 1989 :

— Voilà, on a ce projet en dBase IV…
— Et dBase IV ne marche pas. (Facile, il suffisait de lire la presse spécialisée).

Sprints à Rallonges

Regulation #8

🗓 T0 + 2 semaines :

— Donc on annule la démo, c’est ça ton idée ?
— On annule la démo, oui : on n’a rien à montrer !

Apprendre et s'adapter

Regulation #7

⌚️ 10h09 : Tom démarre sa première mission. Son client et lui finissent le tour du projet. 🏢

— …En tout cas merci d’avoir pu te libérer si vite. On est un peu dans l’urgence en ce moment.
— Pas de souci. Si ça peut aider, pour moi c’est avec plaisir.
— Tant mieux. Comme je te le disais, on a pas mal de régressions sur le projet.

Des usines et du sable

Regulation #6

Merci @JohanMartinsson pour ta contribution à cette conversation sur le mythe de la “Software Factory”. Tu vois 2 facteurs importants de ténacité de ce mythe :

🎤 1. Le confort d’imaginer que l’on peut rester dans la zone de compétence (dev) plus ou moins entièrement. Ca peut être assez plaisant d’imaginer que l’on va juste réaliser les idées des autres

Mégapole

Regulation #5

Imaginez une mégapole où on circule de mille façons, tramway, métro, vélo, moto, auto… Il y a dans cette immense agglomération des infrastructures fiables, sûres et pratiquables. Tout est fait pour la circulation : chaque véhicule arrive à sa destination, chaque transporteur, chaque passager atteint son objectif.

🏙🚟🚲🛵🏍🚗🚐🚛🌆

Cliquets

Regulation #4

Alors que la revue commence, un portable sonne bruyamment.

— Oups, pardon.

Dans la salle de réunion, 4 autres participants vérifient leur portable. 2 d’entre eux le mettent en sourdine.

Crash Fatal

Regulation #3

C’est l’histoire d’une fonction qui rencontre une variable.

Prévenir > Guérir

Regulation #2

TDD est une stratégie Diviser pour Régner appliquée aux vérifications et aux refactorings de votre code. Le R.O.I, ce que vous gagnez à acquérir et renforcer cette compétence, dépend de la taille de la base de code sur laquelle vous travaillez.

Interactions

Regulation #1

ART (Artful Rhetoric Technics) et BOX (Brave Orators eXpressing) sont deux entreprises en compétition sur le marché du service d’éloquence, i.e la production de discours délivré en présentiel (communication d’entreprise, célébrations, etc.).

Soirée Meetup

Producteurs #10

— Non, mais je t’arrête, on a zéro besoin de TDD, DDD, Clean Code pour réussir.

Amélioration Continue

Producteurs #9

Hier j’illustrais le fait que pour beaucoup d’équipe de développement, la manière la plus simple et la plus courante de produire plus vite consiste à remettre à plus tard les choses qui prennent du temps. 🐌 🐇

Productivité

Producteurs #8

Victor — appelons-le Victor — est développeur. 🤓

Dans son travail, il trouve toujours des moyens d’aller un peu plus vite. ⏱

Nouvelles Conversations

Producteurs #7

Il a fallu 2 décennies, et l’amélioration constante des outils d’intégration et de déploiement en continu, pour faire du dialogue entre le Métier et la Technique une réalité quotidienne (ou au moins hebdomadaire) du développement de logiciel dans l’entreprise.

Etat de l'Art et Nouveauté

Producteurs #6

Notre capacité à documenter, améliorer, transmettre, en un mot faire vivre un état de l’art quel qu’il soit n’a jamais été aussi grande.

Elle ne semble dépassée que par notre motivation à remplacer ce que nous construisons le plus rapidement possible.

Software Factory

Producteurs #5

Dans le vocabulaire des ESN et de leur clients, le mythe de la “software factory” est étrangement tenace. 🏭

Producteurs de Code

Producteurs #4

Merci Amael BERTEAU d’avoir cité Sandro Mancuso :

🎙 Les développeurs qui ne comptent que sur leurs entreprises pour leur fournir des connaissances ne sont pas des développeurs de logiciels professionnels. Ce ne sont que des ouvriers d’usine déguisés.

J'ai un mystère

Producteurs #3

Une équipe de développement modifie un logiciel et lui ajoute des comportements possibles.📲

Certains de ces comportements sont indésirables : l’équipe s’efforce de les extirper du logiciel.🗑

Travailler tard avant d'être remplacé

Producteurs #2

Dans certaines entreprises, en l’absence d’extincteurs, on promulgue l’interdiction des incendies.

On déclare : L’échec n’est pas une option !

📜📯

Cavalcade

Producteurs #1

♔♕♟♗ Jusqu’à la fin de la partie, les observateurs se sont tus. Puis ils commentent :

Engagements

plateaux #10

Il arrive qu’une équipe (Technique + Métier + Management) améliore son état de l’art au point qu’elle en fait une “plateforme”. 🌉

Une plateforme s’obtient par une série (parfois longue) de changements de “plateau”.

Amélioration Continue

plateaux #9

Merci Andrea Chiou pour ta contribution à cette conversation ainsi que pour ces questions concrètes à propos d’améliorations de l’état de l’art d’une équipe.

❓ Qu’est-ce qu’une entreprise perdrait en essayant de construire sa plateforme ? Nous pouvons clairement voir dans tes posts ce qu’elles gagneraient. Quel serait l’investissement ?

Plateformes

plateaux #8

Il est impossible de vraiment “représenter” un état de l’art. Au prix d’une réduction de ses multiples dimensions cependant, on peut tenter de le mettre en diagrammes, un peu comme on le mettrait en boite. 🔲

État de l'Art

plateaux #7

Pour documenter l’état de l’art complet d’une équipe à un instant t, il faudrait produire :

Sens Partagé

plateaux #6

— Je ne sais pas vraiment quoi penser de ton travail, dit ce manager à ce développeur.

Nouveaux Plateaux 🌄

plateaux #5

J’ai utilisé TDD pour la 1ère fois en 2001, sur un projet en crise. 🤸

Ralentir : Crise

plateaux #4

🔥 Dans un projet en crise on a généralement très peu de marges de manœuvre. 🚒

Il faut parer au plus pressé, “sauver les meubles” comme on dit.

Fatalités ?

plateaux #3

Merci Cédric Crevier pour ta contribution à cette conversation ! Le paradoxe d’un projet correctement cadré qui perd de sa cohérence en cours de réalisation peut en effet s’expliquer facilement si l’on prend ton hypothèse (fréquemment observée) des incitations perverses (c’est à dire au fond des politiques détournées de leur but) :

L'idéal ?

plateaux #2

Dans un processus de développement idéal, chacun piocherait une user story dans la pile des US à réaliser, réaliserait toutes les tâches attachées à cette US dans les temps estimés, poserait cette US sur la pile des US à valider, piocherait la story suivante etc.

L’idéal ? Peut-être. Le rêve, non. Le cauchemar, oui.

Le Projet de Dorian Gray

plateaux #1

Une personne utilise une cafetière moka pour la première fois, rate son café, comprend son erreur, et recommence, avec succès. Ensuite, elle ne rate plus un seul café réalisé à l’aide de cette technique. ☕️

Une organisation lance un projet, rate le projet, comprend son erreur, et recommence, sans succès. Ensuite elle continue de rater et de recommencer projet après projet. 🚧🕳

Ce n'est pas une question de rôle

product owning #9

La dette, ce n’est pas une question de rôles usurpés.

Scrum à la Rescousse 🕳 🚑

product owning #8

Merci Cédric Crevier pour ta contribution à cette conversation sur DT et PO !

Face au faux-dilemme “livrer des stories vs résorber de la dette” tu suggères (et je suis 💯 👍) de suivre Scrum, notamment les prérogatives propres à chaque rôle.

Un PO n’a pas à dire s’il faut refactorer ou non 🔑

Examiner des conflits 🪑 🕳 🔦

product owning #7

Merci Anaël Ichane de te joindre à notre conversation !

La discussion (vécue) que je mets en exergue comme un exemple de conflits d’objectifs possède juste ce qu’il faut de drame pour attirer notre attention. Les projets heureux n’ont pas “d’histoires”.

Expressions de Besoins

product owning #6

🚉🏗🏭🏦🧪📺🏢 → 👨‍💻

Dans mon travail, depuis des années je traite des besoins Métier. Certes avec l’arrivée des approches agiles il y a 25 ans, la démarche de “recueil des besoins” s’est métamorphosée (et heureusement). Mais la direction de “l’expression de besoins” n’a pas changé :

Horizons Bouchés, Nuages de Conflits

product owning #5

À l’ordre du jour du “sprint planning” du lundi matin, figure une “User Story Technique” :

Les développeurs, à la suite d’une revue de la conception, proposent une tâche importante de remaniement, qui devrait occuper une partie de l’équipe pour plusieurs heures. Faire ce refactoring, c’est renoncer à livrer une voire deux stories à la fin du sprint.

🏷 Patterns et Conflits ⚔️

product owning #4

À propos de mon exemple d’hier :

prixTTC = prixHT * 1.20 partout dans le code,

Zombies

product owning #3

Une application qui contribue pleinement à la création de valeur dans l’entreprise mais dont la conception n’est plus vivante, est ce qu’on appelle dans notre jargon technique une application “legacy”.

conflit d'idées

product owning #2

Merci Laurent Prost et Mauko Quiroga Alvarado pour vos contributions à ma réflexion d’hier sur ce système à 3 acteurs qui modélise pour moi le developpement.

Si cette conversation tendue entre un Tech Lead et son Manager à propos du pilotage fonctionnel et technique du projet nous évoque un Mexican Stand-off plutôt qu’une saine relation de collaboration, c’est parce qu’il y a conflit.

Jonglerie

Product Owning #1

— Qu’est-ce qui pourrait te convaincre de rester ? demande le manager au développeur démissionnaire.

Nouveau! 📯

Product Owning #0

Le développement de logiciel est essentiellement une activité de traduction, de conception et de construction. Les modèles d’organisation qui ont cours depuis plusieurs décennies dans l’entreprise ne reflètent pas cette réalité. Dans l’entreprise, on met plutôt l’accent sur le produit (comme dans “product owner”), sa livraison (“delivery”), et sa fabrication (“software factory”).

Sens Partagé

Sortir des ronces #9

Bienvenue dans cette conversation Sami Hadhri! Tu évoques un chemin peu fréquenté pour se sortir des ronces de la dette technique :

ça me rappelle une décision contre intuitive et critiquée de notre CTO quand j’étais chez Reuters. Il a décidé d’arrêter les features et de passer quelques mois sur l’absorption de la dette et la réarchitecture du produit.

Crise de Croissance

Sortir des ronces #8

Toutes les fois où un Tech Lead m’a annoncé “cette application, c’est la vache à lait de l’entreprise” il m’a ensuite montré du code legacy.

Boule de Cristal

Sortir des ronces #7

Une équipe de 5 développeurs, un product owner et un manager, ajustent leur état de l’art : on passe de Trelli à Jora. (Jora permet de requêter les tickets, ce qui permet de produire toutes sortes de rapports intéressants, ce qui améliore la communication du projet).

4 semaines plus tard, elle décide de faire le chemin inverse.

Lit de Procuste

Sortir des ronces #6

Il y a environ 25 ans, une de mes toutes premières missions de conseil a consisté à auditer la conception d’une application Visual Basic installée dans des agences, et qui permettait entre autre d’imprimer l’organigramme de l’agence : une simple arborescence de rectangles contenant chacun un nom de service et un nom de responsable.

Construction de Théorie

Sortir des ronces #5

Merci Arnaud pour ta contribution éclairante à cette conversation !

🎤 Est-ce que la “dette technique” n’est pas aussi, et même souvent, une situation analogue à celle du changement de paradigme décrit par Kuhn ?

Pro Tips

Sortir des ronces #4

La dette technique, c’est le bilan qui sort comme d’une enveloppe lorsque l’équipe (au sens large, c’est à dire incluant la Technique, le Métier et le Management) fait le point sur l’état de l’art du projet.

Prérequis

Sortir des ronces #3

Dans mon post précédent je mentionnais l’article captivant de Jérémy 🧑🏽‍🦱 Buget qui relate une action de fusion de versions particulièrement intéressante, et je notais un des points importants qu’il retient de cette expérience et qui ont fonctionné :

• Courage, méthodologie, rigueur et patience.

Sortir des Ronces

Sortir des ronces #2

Le temps a passé. La conception de notre application a perdu en élégance et en cohérence. Certaines parties du système sont sanctuarisées : on n’ose plus y toucher. On cherche des développeurs·ses expérimenté·es, si possible des expert·es de cette technologie qui était tellement hype il y a cinq ans. Mais sur le marché de l’emploi et du service, tout le monde est passé à autre chose. La solution est devenue un problème.

Qualité, Coûts, Délais

Sortir des ronces #1

Je viens de lire avec beaucoup d’intérêt le post d’Anthony Cyrille qui commence par cette malicieuse accroche :

“Mon développeur est très compétent, il a développé tout le projet en une semaine.”

👀

Contre-Effet de Levier

Sortir des ronces #0

Bienvenue Mauko Quiroga Alvarado dans cette conversation ! Merci pour cette réflexion :

Pour moi la dette technique c’est une CAPEX, c’est un choix volontaire et rationnel avec un engagement de remboursement. Soit tu la paies, soit c’est un/e autre qui le fait. L’exemple classique du client à forfait qui ne veut pas de tests : il paie moins cher en échange de dette technique. Si on sait bien ce qu’on fait (presque jamais), cela peut être même un choix justifié.

Conversations, Observations

À la recherche de la cohérence #10

La scène se passe au restaurant de l’entreprise où je suis en mission. La conversation avec mes coéquipiers porte sur le prix du mètre carré, et sur l’épargne. Je m’apprête à donner mon opinion, mais je me rappelle que je viens juste de contracter un prêt afin de combler un découvert, et je me ravise.

Finalement, j’avoue :

— Oh moi, je n’arrive pas à économiser. Je sais que je pourrais, mais c’est plus fort que moi.

Factory

À la recherche de la cohérence #9

Il y a 25 ans, j’ai travaillé pour un temps dans une société qui réalisait des développements au forfait. Cette société comprenait une Direction de la Qualité, laquelle avait mis en place une méthodologie de développement dont l’essentiel tenait à peu près dans 5 gros classeurs. L’un d’eux contenait la prescription suivante :

Métaphores

À la Recherche de la Cohérence #8

La dette technique est une métaphore utile, mais ce n’est pas un indicateur. Elle indique vaguement qu’un certain nombre d’évènements qualitatifs sont survenus sur le projet. On ne peut pas réellement compter ce qu’on a accumulé ou retiré de ce sac là.

Cohérence Perdue

À la recherche de la cohérence #7

Le projet de développement sur lequel vous travaillez actuellement produit subrepticement ou ouvertement ce que tout le monde convient d’appeler de la “dette technique”.

Comment est-ce que je le sais ? Toutes les personnes de ma connaissance qui travaillent dans le développement me parlent de la DT. Tous les projets que j’ai pu approcher, accoster ou prendre en charge dans ma carrière comportaient de la DT.

État de l'Art, Cohérence et Dette Technique

À la recherche de la cohérence #6

L’état de l’art d’un projet perd inéluctablement de sa cohérence au cours du temps, car celle-ci est fortement liée au contexte.

Outillage

À la recherche de la cohérence #5

Notre difficulté principale, ce n’est pas de mettre en œuvre une application basée sur la technologie, c’est plutôt de maintenir la cohérence de l’état de l’art qui guide son évolution.

La technologie change constamment, et nous nous employons à la faire marcher. Nous y consacrons pas mal de temps, d’argent, d’énergie et de motivation, souvent trop, mais on s’en sort. Nous adorons, au sens religieux du terme, les nouvelles technologies. Or celles-ci s’empilent, mais ne s’emboîtent pas.

État de l'Art et Cohérence

À la recherche de la cohérence #4

Dans mon post précédent, je propose une nouvelle définition :

La dette technique, c’est un état de l’art qui se désaligne.

Déspécialiser

À la recherche de la cohérence #3

Mon prof de Français avait conclu notre dernier cours de 1ère avec un conseil d’apparence anodine : méfiez vous de la spécialisation. Je m’étais promis d’essayer de m’en souvenir à l’époque, mais en toute honnêteté je n’avais pas idée de ce qui m’attendais dans le monde du travail.

3 Sources sur la Dette Technique

À la recherche de la cohérence #2

Sur les conseils de Stéphane Dalbera, je lis en ce moment Managing Technical Debt (cf ref en commentaire). Le livre foisonne d’exemples et de modèles, et propose de nombreuses heuristiques ainsi qu’un plan de recouvrement de la DT. Le chapitre 1 offre cette définition :

À la Recherche de la Cohérence

À la recherche de la cohérence #1

Considérons une application qui a 5 ans d’existence. Elle forme dans l’entreprise un petit foyer d’activité autour duquel gravitent des acteurs Métier, Technique et Management occupés à traduire ensemble des idées vers la technologie, à négocier des fonctionnalités et à maintenir l’existant.

Quel Problème Essayons Nous de Résoudre Ensemble ?

À la recherche de la cohérence #0

Quel problème essayons nous de résoudre ensemble ?

C’est ma question préférée. Elle peut être incisive, à en juger par les réactions qu’elle provoque parfois :

Mission Failed ?

Dette Technique #12

Janvier 2018 : un projet démarre, une équipe se met en place, on fait un cadrage, un chiffrage, on réalise, puis on fait évoluer une application.

Janvier 2023 :

🙂 l’application est en succès : elle contribue aux bénéfices de l’entreprise depuis bientôt 5 ans !

Une Facture Imaginaire

Dette Technique #11

Poncifs :

👉 Un projet de développement logiciel est une opération affreusement compliquée. Nous simplifions les choses parce qu’il faut bien passer à l’action.

Retour d'Information

Dette Technique #10

Le développement de logiciel est un travail complexe. Pour simplifier ce travail, nous le divisons :

Un Levier de Vitesse

Dette Technique #9

Product Owner et Dette Technique

Telle que présenté par Ward Cunningham, le pattern Dette Technique est un curseur avec lequel l’équipe peut “jouer” : face à un objectif intermédiaire important et urgent, elle peut décider de déroger temporairement à son état de l’état de l’art, quitte à réaliser par la suite un effort supplémentaire pour revenir au standard.

Le Rôle du Product Owner

Dette Technique #8

Dans mon post précédent, j’affirme que le pattern Product Owner :

🏷 rôle définissant les responsabilités et prérogatives liées à la traduction en application, des idées élaborées avec le Métier

permet à une équipe de limiter sa dette technique, c’est à dire de prévenir ou de mitiger le désalignement de son état de l’art.

Comment est-ce possible ?

Pratiques de Prévention

Dette Technique #7

La dette technique, c’est un rebut, présenté comme un fait accompli. La dette passée nous empêche de faire évoluer rapidement le logiciel. Mais la dette future, nous la paierons plus tard, il y a plus urgent dans le backlog.

Que faire ?

Un État de l'Art Désaligné

Dette Technique #6

Stabilité du code. Le code Forth écrit sur mon C64 il y a 40 ans “marche” encore. Lancer ce code aujourd’hui sur une telle machine me serait difficile, coûteux (et inutile), mais ce code, lui, n’a pas bougé. C’est tout le reste qui a changé.

De même pour le code que nous avons déployé en production il y a 3 mois. Il ne subit aucune altération, et pour peu que nous sachions comment le redéployer via un plan de secours, il est en sécurité.

Tout le reste va changer. Voici ce que nous allons découvrir :

Le Rôle du Management

Dette Technique #5

Thèse : Le développement de logiciel comporte un coût caché lié à la mauvaise qualité du code et/ou du leadership technique, la dette technique, qu’il revient à la Technique de réparer sous peine de grever le budget des évolutions fonctionnelles futures.

Au Cœur du Processus

Dette Technique #4

La dette technique, vue depuis le modèle Développement = Production :

Une Traduction Incohérente

Dette Technique #3

La dette technique, c’est donc juste une façon de parler. Mais de parler de quoi, au juste ?

Pour Ward Cunningham à l’origine, contracter une dette technique, c’est prendre un raccourci sur notre état de l’art et nos standards le temps d’atteindre un objectif intermédiaire. Une tactique à n’utiliser que ponctuellement, sous peine de se sur-endetter.

Chiffrer la Dette ?

Dette Technique #2

La dette technique ce n’est pas de la dette, et ce n’est pas technique.

Lorsque nous disons que le code d’une application présente de la dette technique, deux simplifications s’opèrent :

1) nous considérons le problème uniquement sous l’angle du code

2) nous convertissons ce problème en euros

La Dette Technique, qu'est-ce que c'est ?

Dette Technique #1

Le code qui tourne à l’instant t sur nos machines est la cristallisation de conversations entre ces 3 acteurs : Métier, Technologie, Management.

Dans une situation de code legacy, le code tourne toujours, mais la conversation n’a plus lieu.

Dans une situation où la conversation a toujours lieu mais est entravée par des barrières de communication, nous disons du code qui tourne sur nos machines qu’il est “endetté techniquement”.

The Bowling Score Kata

As I am currently rereading Leo Brodie’s Thinking Forth, I am amazed about how most of the program design tips in this 1984 book are still relevant today. The author’s first book, Starting Forth initiated a life-long love story with programming for me, and Forth is still one of my favorite languages. In this post I will try to convey a sense of the Forth philosophy while solving the popular Bowling Score Kata using gforth. Although doing TDD in Forth is very easy, I choose to not include the tests in this post in order to keep it short.

Coding Katas and Problem Solving

For years I have been practicing around coding katas at the Developers Dojo in Paris. What I like about coding katas in the context of a programming Dojo is that these exercises are generally based on simple, well-defined problems that are easy to explore. In that way, they present us with an opportunity to improve our problem solving skills as well as our coding skills.

What Problem Are You Solving Together?

”What problem are you solving together ?” is by far my preferred question at work, and probably the most powerful, too. It can be quite incisive, if the reactions it creates are any measure:

Scratching the surface of Monad Transformers

Haskell makes it possible to write statically typed, purely functional programs. This gives us two interesting conveniences. The first one is that any incoherence in the type of our expressions and sequences can be spotted at compile time. The second one is that we can rule out the direct use of partial functions by wrapping their results in new data types and compose expressions with values of these types.

The Diamond Kata: a mix of TDD and PBT

In this post I show an example of solving a coding kata the TDD way, while writing “property based testing” checks with QuickCheck.