Pourquoi faire simple quand on peut faire compliqué ? – Extrait d’une discussion chez OCTO

Introduction

Cet article n’est pas un article comme les autres, c’est un extrait brut de discussion que nous avons sur notre mailing-list “tech” interne, un bout de la culture OCTO.

tech : L’objectif de cette mailing-list est d’échanger entre OCTO sur des sujets techniques, on y retrouve des demandes d’aide sur un sujet ou une architecture technique, des REX (retour d’expérience) sur des technologies ou des missions, des échanges d’opinions ou de convictions, des partages de savoir, et beaucoup de débats.

l’objectif de l’article : En écrivant ce mail (celui qui commence le thread sur tech), j’avais le sentiment qu’il n’y a pas une seule bonne approche pour traiter de simplicité et de complexité, ce qui m’intéressait c’était de partager ma réflexion et d’avoir celle des autres. Je tiens à remercier ses contributeurs.

Aujourd’hui, en le mettant sous forme de publication, nous voudrions élargir ce débat avec les réflexions des lecteurs de ce Blog.


Le Thread


Benjamin Joyen-Conseil

29 sept. 2020, 20:12:23 à tech@octo

Salut tech

tl;dr : faire simple c’est compliqué, mais pourquoi ?

Je me pose la question en ce moment du comment en arrive-t-on à des systèmes aussi compliqués parfois (trop souvent ?) dans nos missions, chez nos clients.

version longue

En arrivant chez OCTO, comme tout le monde, j’ai appris les acronymes comme KISS, parmi d’autres.

J’ai l’impression que je l’ai utilisé trop souvent, sans avoir le recul qui va avec, car j’étais peut-être frustré de voir trop souvent des gens construire des systèmes informatiques sophistiqués, trop compliqués pour atteindre leur but, qu’ils s’encombrent le cerveau et celui des autres avec ce comportement.

D’abord, je brandissais KISS de façon à faire prendre conscience à mon interlocuteur le décalage entre son design et le besoin fonctionnel. Mais je me suis rendu compte que ce n’étais pas du tout juste, parce qu’apprécier un design comme étant simple c’est très relatif et subjectif.

J’ai noté qu’il y a plusieurs situations où le sur-design peut se produire :

  • Quand il y a un décalage de compétence et de connaissance entre 2 parties (personnes ou plus largement des équipes). Les uns maîtrisent Docker et les autres sont sur Windows. Cela amène des gens à bricoler sur des choses qu’ils ne maîtrisent pas
  • Quand il y a un manque d’expérience sur la stack techno et que les gens sur le projet on envie de faire joujou, l’explorer, voir ses limites. Cette attitude est néfaste, mais qui n’a pas déjà fait cela en mission ? Il serait hypocrite de le nier, mais il y a sûrement un équilibre à trouver
  • Quand l’équipe n’arrive pas à avoir une vision d’ensemble pour savoir se positionner au bon endroit quand il faut modifier ou faire évoluer le système.
  • Quand le temps imparti pour faire l’évolution est trop court, et la mission se termine avant d’avoir terminé l’implémentation
  • Quand le besoin fonctionnel est mal exprimé et donc amène les gens à interpréter ou anticiper

Il existe aussi bien sûr des combinaisons de ces situations. Sûrement parce que nous intervenons dans des contextes où les presta vont et viennent, ça laisse souvent les choses inachevées, avec des niveaux différents de (in)compréhension. Le temps fait aussi sa part.

Parmi ces situations j’en retire principalement que, faire simple signifie (entre autre) :

  • avoir des connaissances et de la maîtrise : quelques abstractions puissantes changent radicalement le paysage : je pense notamment à Git pour le développement en équipe, Docker pour le packaging, Kubernetes pour la gestion de services distribués communicants, le SQL pour manipuler des données, etc… Se reposer dessus rend les choses plus simples pour ceux qui maîtrisent l’abstraction.
  • du temps et de l’expérience : la recette qui s’applique chez l’un, est à contextualiser chez l’autre. L’expérience donne du discernement mais il faut quand même un esprit critique à la base. Construire quelque chose de puissant demande souvent des assemblages sophistiqués, mais plus le temps avance et plus l’expérience nous permet de savoir ce qui important de ce qui ne l’est pas.
  • savoir se positionner dans la cartographie du système : ce qui peut-être simple à l’échelle macro est en réalité compliqué à implémenter à l’échelle micro. Cela nécessite de savoir jouer avec les abstractions, monter ou descendre de niveau quand il le faut. Cette compétence requiert une connaissance des niveaux d’abstractions, puis de descendre de niveau quand le positionnement courant est limitant (ex : j’utilise un ORM pour mon application, mais celui ci a de gros souci de perf => je dois aller comprendre le niveau d’en dessous)
  • supprimer / décommissionner régulièrement des parties du système : ce dernier point est crucial à mes yeux. C’est malheureusement l’aspect qui est le moins valorisé et le plus souvent oublié dans le processus de simplification. Ajouter quelque chose nécessite de supprimer l’ancienne façon de faire, sinon on est sur un système bancal, comme une maison sur pilotis.
  • être précis dans l’expression du besoin. Elle doit aussi se situer correctement dans la cartographie du système et indiquer clairement la verticale qu’elle impacte. Le découpage par étape est important, il permettra de construire petit à petit sans faire de stock (YDNIY)

Un système simple qui se complexifie au cours du temps, vous l’avez peut-être déjà observé. Ça m’arrive personnellement régulièrement.

Je me dis qu’il y a plusieurs explications à ça :

  1. Les équipes sont toujours plus autonomes (on tend vers ça). Ça amène les gens à choisir ce qui leur plaît, soit par sécurité (je connais Python, je vais sur du Python), soit par challenge (j’ai vu Kotlin, j’aimerais bien en faire). Qui challenge tout ça ?
  2. L’externalisation des compétences IT est omniprésente chez nos clients, l’évolution et la maîtrise du SI en devient très compliquée, voire impossible. Pas de connaissance, pas de chocolat.
  3. On n’aime pas dé-commissionner car cela implique de vérifier / connaître une ancienne partie dans laquelle il est fastidieux de naviguer. De toute façon, ce n’est pas nous qui avons cautionné cette bouse !

Qui va sauver le monde ?

J’ai l’impression qu’avoir un regard neuf régulièrement sur ce qu’on a réalisé est important, elle apporte

  • un regard différent dans la compréhension du problème;
  • des nouvelles connaissances et angle d’attaque différent;
  • elle permet de se mettre à jour => en effet, les outils et framework sur lesquels nous nous reposons évoluent vite et ce qui n’était pas possible il y a 6 mois l’est devenu plus récemment. On peut donc avoir pris une (bonne) décision 6 mois auparavant qui n’est plus la plus simple depuis.
  • elle fait prendre du recule au gens qui ont parcouru du chemin sans avoir eu l’opportunité de le faire sur ce chemin parcouru.

Quelqu’un qui dit à un nouvel arrivant sur le projet « On a voulu utiliser ça il y a 1 an et ça ne marchait pas du tout, donc non on ne va pas faire ça » – il m’arrive d’être comme lui – cette personne doit laisser la place aux propositions d’évolution, quitte à ce que ça donne exactement le même constat après analyse.

Les choix ne sont valables que pour une période, et rarement durables dans le temps. Les contraintes et les choses impossibles ne sont contraignantes que temporairement.

Je me dis aussi que peut-être si nous avions toujours un rappel pour plus de focus sur la finalité : l’utilisateur ou l’écosystème impacté; cela nous aiderait à rester sur l’essentiel pour atteindre notre but.

Ce sont mes réflexions du moment, mais j’aimerais avoir les vôtres sur la question, échanger et débattre avec vous :)


Sara Wino Jolivet

29 sept. 2020, 21:08:42 à Wassel Alazhar

Cela m’évoque une conf que j’avais regardé sur la documentation d’un système par un certain Marc Bojoly qui disait au sujet des systèmes legacy(j’espère ne pas mal me souvenir) :  qu’il était plus judicieux pour le futur de documenter les raisons de choix techniques en donnant les éléments d’un contexte qui ont amené la décision plutôt qu’une documentation exhaustive de son fonctionnement. En gros : contextualiser pour aider ceux qui hériteront de l’évolution du système et des décisions afférentes.

Ça m’évoque aussi la culture d’entreprise… que j’imagine ont doit pouvoir deviner en ouvrant le capot.


Nelson da Costa

30 sept. 2020, 07:42:38 à Sara Wino Jolivet,

Ce à quoi faisait référence Marc sont les ADR, que l’on avait mis en place dès notre arrivée sur ce projet à fort endettement.

Cette pratique doit devenir un standard pour lutter contre cette forme d’entropie logicielle.

De mon expérience, plus on reste longtemps sur un projet, plus on est responsable de devoir dé-commissionner activement car on fait partie de ceux qui savent « pourquoi » certains choix ont été fait, et ça c’est un des éléments cruciaux pour être capable de décommissionner sereinement.


Christophe Thibaut

30 sept. 2020, 09:14:29 à Benjamin Joyen-Conseil,

Une chose m’a frappé en particulier : les situations d’over-engineering que tu as observé :

  • décalage de compétence et de connaissance entre 2 parties
  • manque d’expérience sur la stack techno
  • envie de faire joujou
  • l’équipe n’arrive pas à avoir une vision d’ensemble.
  • temps imparti pour faire l’évolution est trop court
  • le besoin fonctionnel est mal exprimé

relèvent à mon sens toujours du même type de situation à savoir : nous (l’ensemble des acteurs (métier+management+tech) impliqués dans ce design/développement) ne sommes pas en train de résoudre le même problème.

C’est notablement le cas lorsque :

– une partie (n’importe laquelle, pas seulement les « tech ») prône un outil que l’autre partie « n’achète pas »

– une partie expérimente (ou fait « joujou ») alors que l’autre demande une « application » (origine du terme = appliquer une technologie à un cas d’usage)

– une partie est au clair avec son propre niveau d’expérience ou de compétence alors que l’autre ignore cet aspect (jetez la première pierre si vous n’avez jamais vu un CV remanié pour matcher une mission. Je serai ravi de recevoir des pierres).

– une partie croit dur comme fer que la solution sera livrée le 31 mars alors que l’autre sait bien que non (anecdotal evidence: on entend la phrase: « ça dépend de ce que tu entends par ‘solution’).

– une partie estime qu’une fiche 3×5 envoyée électroniquement aux développeurs = un bon de commande, l’autre partie escompte clarifier cette user story au fur et à mesure de sa réalisation.

Dans chacune de ces situations, des éléments — parfois cruciaux — du problème posé, des objectifs, des contraintes, des méthodes à utiliser pour le résoudre sont manquants ou incomplets ou ambigus.

C’est le but du cadrage de projet d’identifier et de résoudre les manques, les lacunes et les ambiguïtés les plus critiques.

Un projet qui produit une solution overkill, c’est bien souvent un projet mal cadré.

Tout ce que nous faisons (tous : développeurs, PO, CP, tech lead, designers, sponsors) gravite autour de la définition d’un problème et de sa résolution.

Or nous avons tendance à définir et libeller nos activités comme si nous avions déjà la solution, que nous sommes prêts à la fournir, la vendre, la « délivrer ». C’est le côté « industrie du service » qui fait la prospérité des ESN, la tranquillité des décideurs, et le détérioration de ce marché par l’effet « market for lemons ».

Une software factory « fabrique » des applications. Où est passée la définition du problème ? En amont de la software factory ? Certainement pas, sinon en amont de la SF on verrait arriver des specs, pas des tickets jira.

L’activité de définition du problème est en fait diffuse à travers toute l’activité du projet. Mais à force de diffusion elle devient transparente, ou bien même s’évapore.

La manière la plus simple de porter un regard neuf sur ce qu’on est en train de réaliser consiste pour moi à poser la question :

quel problème sommes nous en train de résoudre ensemble ?

Les réponses à cette question sont toujours riches en pistes d’amélioration.

NB : le fait que le problème ne soit jamais parfaitement défini est inhérent à tout projet d’ingénierie qui ne sort pas d’un manuel scolaire. Il est vain de chercher la cohérence absolue. Ce n’est pas le but. Le but est de détecter, de traquer et de remédier les cas d’incohérence qui passent habituellement « sous le radar » de notre rationalité aiguisée au spécifique. « Plus d’expertise » n’est pas la panacée car l’expertise crée des compartiments et provoque des transferts de responsabilités tacites.

– quel problème sommes nous en train de résoudre ensemble ?

… (deux heure de discussion)

– conclusion : c’est pas cohérent ce que nous sommes en train de faire.

(décision : recadrage de projet à mi-chemin de la roadmap).

NB : résoudre un problème ensemble demande souvent plus de sacrifice, de prise de risque, de perte de points en capital social, de passages sur le grill, que « faire avancer un projet ». Toutes les grosses solutions endettées par sur-design étaient des projets qui avançaient.

€0.02


Mathieu Poignant

30 sept. 2020, 09:17:58 à Nelson da Costa,

Séquence nostalgie : Youtube – Marc Bojoly : « Restructurer un legacy : pourquoi et comment ? »


Florent Jaby

30 sept. 2020, 14:04:09 à Christophe Thibaut,

Je remets une pièce suite à CTH.

Pour moi ce que tu décris Benjamin rentre plus ou moins effectivement dans le cadre d’une incompréhension partagée de l’espace du problème et de l’espace de la solution. <insert double diamant here>. Comme il y a beaucoup plus de manières de ne pas se comprendre que l’inverse, il y a toutes les déclinaisons que tu proposes.

Pour aller piocher dans d’autres références, la perfection est atteinte non pas quand il n’y a plus rien à ajouter mais bien quand il ne reste rien à enlever. Outre le concept de perfection que ne s’applique pas ici, je pense que l’on est collectivement pas assez enclin ou discipliné à entreprendre les phases de réductions du double diamant. On peine à renoncer (collectivement) à certains aspects du problème et de même à renoncer à certains aspects des solutions.

Les problèmes surviennent donc quand on arrive pas à renoncer ou que tout le monde ne renonce pas aux mêmes choses ^^

Certains biais cognitifs connus, individuels ou collectifs, sont à l’origine de notre aversion au renoncement et il suffit de faire ses courses https://fr.m.wikipedia.org/wiki/Biais_cognitif.


Benjamin Joyen-Conseil

30 sept. 2020, 17:57:47 à Florent Jaby,

@Florent Jaby

Je ne cherche pas à faire le système parfait parce que je sais qu’on peut courir après toute la vie. Chaque abstraction / système a ses limites, ses fuites, ses zones d’ombres qui ne sont pas top (parmi ceux que j’ai cité Git, Docker, Kub sont bien connus pour en avoir).

Ma démarche est de me dire « c’est comme ça, comment mieux faire avec ?”

Un projet qui produit une solution overkill, c’est bien souvent un projet mal cadré.

@Christophe Thibaut :

Je pense que c’est une des raisons en effet, mais pas la seule. En fait, il est facile pour un développeur de faire du sur design même si le projet est bien cadré. La référence aux biais de @Florent Jaby est intéressante d’ailleurs.

De plus, il est rare que le problème soit complètement limpide, car il y a des problèmes qui demandent d’être abordés avant de comprendre l’étendu du sujet, il y a des projets qui pivotent ou cherchent leur cible.

Dans ces 2 exemples, ce que je retiens c’est que la réponse est la même : reposer la question « que sommes nous en train de résoudre » à chaque fois qu’une variable de l’équation bouge.

NB : le fait que le problème ne soit jamais parfaitement défini est inhérent à tout projet d’ingénierie qui ne sort pas d’un manuel scolaire. Il est vain de chercher la cohérence absolue.

Oui tout à fait, faire la chasse à toutes les anomalies serait faire excès de zèle et irait à l’encontre d’une des règles d’or : Working software over comprehensive documentation

 

Il était plus judicieux pour le futur de documenter les raisons de choix techniques en donnant les éléments d’un contexte qui ont amené la décision plutôt qu’une documentation exhaustive de son fonctionnement.

@Sara Wino Jolivet c’est une astuce très intéressante pour transmettre et rendre une utilité à la documentation. Elle n’évite pas le sur-design de la personne qui l’a précédée, mais peut lui faire prendre conscience de la complexité de ce qu’elle a réalisé. Cela me rappelle beaucoup le fonctionnement des gros projets Open Source qui fonctionnent avec des descriptions technico fonctionnelles des évolutions indiquant les motivations. L’exemple que j’ai en tête est Python avec les propositions d’évolution PEP


Alexandre Siguier

30 sept. 2020, 18:17:17 à Benjamin Joyen-Conseil,

Et tu peux ajouter à toutes ces raisons, le fait que les ingénieurs sont formés à « gérer la complexité » et que ce « pli » (certains diraient habitus) ne se change pas facilement, surtout dans des organisations qui valorisent les personnes qui ont mené des projets complexes (et qui entretiennent donc l’habitus d’ingénieur).

Ou pour le dire plus trivialement : c’est plus classe de faire un truc compliqué qu’apporter une solution simple.

Combien de fois ai-je perçu de la déception d’un client face à une solution simple, voire même le refus d’une solution jugée trop simple.


Vincent Guigui

1 oct. 2020, 18:54:19 à Alexandre Siguier,


Alexandre Jeambrun

1 oct. 2020, 11:01:01 à Vincent Guigui,

Mes 2 cents : la question de la complexité accidentelle vs la complexité essentielle :

https://medium.com/background-thread/accidental-and-essential-complexity-programming-word-of-the-day-b4db4d2600d4

« Essential complexity is how hard something is to do, regardless of how experienced you are, what tools you use or what new and flashy architecture pattern you used to solve the problem. […]

Essential complexity is a property of the problem you are trying to solve.

[…]

While some complexity is inherent to the problem, we also bring our own complexity while writing the program. This is called accidental complexity. »


Ali El Moussawi

1 oct. 2020, 20:29:12 à Benjamin Joyen-Conseil,

+1 @Alexandre Siguier sur le pli à déconstruire « il faut une solution complexe », comprendre « une solution simple n’est pas digne de mes capacités d’ingénieur »

Je réagis sur l’idée de « supprimer / décommissionner régulièrement des parties du système » je suis d’accord que c’est crucial.

Le gros obstacle à mon sens est aussi un biais cognitif.

De la tendance (moi le premier) à commenter un code plutôt qu’à le supprimer, à la volonté de continuer d’exploiter un logiciel « qu’on a mis tant d’énergie à construire », le blocage n’est pas seulement dû à un refus d’admettre son « erreur ».

Il y a aussi à mon sens une tendance à considérer le logiciel comme un actif (asset) qu’il faut rentabiliser.

Peut-être suggérer à nos clients que le vrai actif c’est la richesse du voyage collectif (journey) qui leur a permis de résoudre un problème avec les outils du moment ?

Et que le fait de dé-commissionner « le machin qui a coûté 2000 jours homme » ne détruit en rien cette richesse, mais au contraire l’augmente par un voyage collectif supplémentaire ?

Ce qu’ils pensent perdre en de-commissionnant est en fait négligeable devant ce qu’ils gagnent en potentiel de meilleure résolution du même problème, et surtout des autres problèmes actuels ou futurs…

0.00000000323 bitcoins


Benjamin Joyen-Conseil

1 oct. 2020, 20:57:48 à Ali El Moussawi,

Peut-être suggérer à nos clients que le vrai actif c’est la richesse du voyage collectif (journey) qui leur a permis de résoudre un problème avec les outils du moment ?

Je cautionne à 200% ce point. Encore faut-il que nos clients n’aient pas seulement que des presta dans leurs troupes.


Philippe Prados

6 oct. 2020, 09:48:31 à Benjamin Joyen-Conseil,

Les échanges sont passionnants. Je partage complètement vos analyses.

Je suis justement confronté à cette situation. Avec le client qui m’a répondu « On ne peut pas faire un truc aussi simple, si c’est pour le vendre des millions à nos clients« .


Christophe Thibaut

6 oct. 2020, 10:08:18 à Philippe Prados,

> Je suis justement confronté à cette situation. Avec le client qui m’a répondu « On ne peut pas faire un truc aussi simple, si c’est pour le vendre des millions à nos clients« .

Traduction : « un concurrent va finir par bousculer le marché, et on ne saura rien faire pour l’en empêcher ».

Ça me rappelle le coup de l’équipe colocalisée avec son métier qui fait en 2 mois ce que la DSI échouait à achever en 2 ans. Q: Mais comment ont-ils fait ? R: Ils ont fait plus simple.


Sylvain Fagnent

6 oct. 2020, 10:35:28 à Christophe Thibaut,

En tt cas il en est un peu conscient car il dit qu’il ne veut pas vendre chère une solution simple……d’autres l’ont fait. Et c’est d’autant plus facile si tu as un monopole……jusqu’à ce qu’apparaisse un barbare

Mais les barbares attaquent alors dès lors que le service rendu par la concurrence est cher et/ou mal opéré voir inexistant; ça lui laisse de la place.

Alors que si ton service est simple, efficace mais pas trop cher….même s’il n’est pas dingo un barbare a plus de mal à s’y mettre. Maintenant si c’est simple et pas cher il en vendra peut-être plus et à des clients qu’il n’imaginait pas avant. Contrepartie, si c’est simple j’imagine que c’est facilement copiable….

En tout cas il est en face d’un autre business model peut-être?  Celui de vendre une solution low cost: simple efficace et pas cher ;-) Son entreprise ne sait peut-être pas se positionner sur ce type de marché qui en effet ne s’appuie pas sur les mêmes ressources, process et valeurs de l’entreprise. Il est peut-être en face d’un dilemme.

Hypothèse yakafautkon ;-): pkoi ne réfléchit il pas au prochain pb de ses clients…..il vient de se dégager des ressources / du temps / argent pour le faire  non ? Le pb de l’entreprise est ailleurs !


Sébastien Roccaserra

6 oct. 2020, 11:55:37 à Sylvain Fagnent,

Ça me fait penser que l’efficience et l’expérience ne sont pas toujours faciles à vendre.

À ce sujet j’aime bien cette anecdote de Dan Ariely :

[…] this locksmith was penalized for getting better at his profession. He was tipped better when he was an apprentice and it took him longer to pick a lock, even though he would often break the lock! Now that it takes him only a moment, his customers complain that he is overcharging and they don’t tip him. What this reveals is that consumers don’t value goods and services solely by their utility, benefit from the service, but also a sense of fairness relating to how much effort was exerted.


Sylvain Fagnent

6 oct. 2020, 14:58:16 à Sébastien Roccaserra,

Entendu en entretien EEO il y a qq années en parlant d’une chose faite dans l’année (on va pas revenir dessus;-)) et en voulant que cela soit valorisé. Cela demandait de l’expérience, ça j’en suis sur ! La réponse : « nan mais ça ça compte pas ! Tu sais bien le faire, ça ne te demande pas de gros efforts » ;-)

Entendu qd j’étais en première ou terminale (ça m’a marqué…la preuve m’en souviens encore), j’avais résolu un exercice de géométrie par une méthode astucieuse, rapide, à laquelle personne n’avait pensée et qui demandait que très peu d’effort …..mes camarades m’ont dit que c’était pas valable car c’était trop facile ;-)…j’ai tt de même eu une bonne note ;-)


Vincent Guigui

6 oct. 2020, 15:32:14 à Sylvain Fagnent,

Le rewards est toujours sur l’effort apparent pour la tâche demandée et non sur les efforts amont pour savoir la faire bien et rapidement (études, années d’expérience, QI…)

Et puis si on voit l’apprenti en galère, on a plus d’empathie pour sa souffrance et le reward est encore plus justifié (même si il s’y est pris comme un manche depuis le début)


Vincent Toqué

6 oct. 2020, 16:44:20 à Vincent Guigui,

« Ce dessin m’a pris cinq minutes, mais j’ai mis soixante ans pour y arriver. »

Auguste Renoir


Christophe Thibaut

6 oct. 2020, 17:04:04 à Vincent Toqué,

Ça me rappelle deux anecdotes (ça s’est passé il y a longtemps mais ça m’avait marqué).

Tech Lead : je pense qu’on a compris la demande, et on pense pouvoir livrer le traitement dans une semaine.

Maître d’Ouvrage : Excellent !

TL : Est-ce que tu pourrais nous transmettre les fichiers de tests (que tu traite actuellement sous excel) afin qu’on vérifie notre programme ?

MOA : Ah bah non ! Ce serait de la triche !

Manager Equipe « Modèle d’Entreprise » : Donc ce qu’il faudrait faire avec ce référentiel, c’est : le comparer à cet autre référentiel, identifier les objet communs, et aussi transposer du ref#1 au ref#2 tous les objets qui ont les caractéristiques suivantes : etc. etc.

Consultant : OK. Je vois. Je m’en occupe.

Mgr : On refait le point dans 2 jours.

4 heures plus tard 

Mgr : Ça va tu t’en sors ?

Consultant : J’ai fini, je pense. Tu peux jeter un œil ?

Mgr : Déjà ? Fais-voir. OK. Mais comment tu as fait ?

Consultant : J’ai fait principalement du grep et puis du awk.

Mgr : C’est quoi ?

Consultant : montre un vague script awk

Mgr : Ah mais non ! Ce que je veux c’est que tu le fasse à la main !

Kamoulox.

 


Quentin Mino

6 oct. 2020, 17:09:01 à Vincent Toqué,

Et j’en profite pour ajouter ma curiosité et ma soif de vos expériences au passage.

Si je comprends bien le début de la discussion, on évoque le lien très étroit entre l’atmosphère, le contexte, le moment présent et la simplicité de ce qu’on construit.

Contexte de me***, délais hyper serrés, équipe junior etc… ==> produit mal foutu, compliqué etc…

Dès que le contexte s’améliore, on devrait refabriquer les parties anciennes pour les simplifier, les améliorer.

On devrait toujours s’efforcer de retravailler le code ancien, ne pas le laisser vieillir ici, qu’importe la raison.

Qu’en est-il dans le cas contraire ?

Un projet qui commence comme sur des roulettes, on fait des sessions de mob programming, on a une couverture de tests en cachemire et du code qui brille, simple, tout mignon…

Puis le contexte change et patatra. Pressions, mauvaise gestion des priorités, mauvaise compréhension du besoin, mauvaise comm… ce que vous voulez.

J’imagine qu’il n’y a aucun intérêt à modifier le code écrit lors de temps anciens plus cléments pour le mettre au goût du jour façon barbare. Mais, y a-t’il un moyen de le protéger, sauvegarder ce qui était simple et performant ? Est-ce voué à l’échec ? (la qualité globale du produit se détériore) Est-ce qu’il y a vraiment un lien entre simplicité et contexte, doit-il y en avoir un ?


Ludovic Cinquin

6 oct. 2020, 17:14:32 à Quentin Mino,

« Je vous écris une longue lettre parce que je n’ai pas le temps d’en écrire une courte. »

Blaise Pascal


Nelson da Costa

6 oct. 2020, 20:19:40 à Ludovic Cinquin,

Des solutions simples, ça ne s’obtient pas du premier coup.

Il y a un travail en continu de raffinement (refacto) qui est nécessaire pour que la solution produite reste la plus alignée possible avec les problèmes qu’elle résout.

Je donne souvent l’analogie du Tetris : tant qu’on fait les bon choix, on est bien pour voir venir et prendre de bonnes décisions, par contre les mauvais choix s’empilent et nous mettent vite dans une situation indésirable où la moindre erreur devient presque fatale.

Je vous partage des articles qui parlent de complexité qui aident à clarifier certains points évoqués:

https://www.lilobase.me/savoir-faire-des-choses-compliquees-ne-fait-pas-de-vous-un-bon-developpeur/

https://www.lilobase.me/la-complexite-une-histoire-de-charge-cognitive/

https://www.lilobase.me/a-complexite-egale-des-realites-tres-differentes/


Yannick Schini

7 oct. 2020, 17:57:23 à Nelson da Costa,

Un point qui n’a pas été évoqué directement je crois, c’est la complexité qui peut-être introduite volontairement par qqn justement pour se rendre indispensable.

J’ai jamais vu une telle pratique chez OCTO (bien au contraire) mais certaines autres boîtes de conseil/presta sont pas au dessus de tels agissements. En tout cas, tout à fait cyniquement, les boîtes de conseil/presta n’ont que peu d’intérêt à produire du code facilement reprenable puisque ça ne fait que faciliter une éventuelle reprise en interne (ou un changement de presta).


Vincent Ducas

8 oct. 2020, 09:12:26 à Nelson da Costa

N’est-ce pas aussi le playbook d’un Archi OCTO ?! 🙂


Philippe Prados

9 oct. 2020, 13:54:02 à Vincent Ducas,

Il y a quelques années, j’ai publié un article sous le pseudo « Jean-Pierre Troll » (le Jean-Pierre Coffe de z), sur « Comment être indispensable« .

Amusez-vous bien ;-)

À relire les autres articles, je m’amuse de notre anticipation des Dockers et compagnies, en remettant en cause les VM, dès 2009 !


Florent Jaby

9 oct. 2020, 16:02:16 à Philippe Prados,

>  On ne va pas donner quatre serveurs à chaque développeur !


To be continued

Le thread se termine. Vous l’aurez constaté, l’objectif n’était pas d’avoir la réponse absolue à cette question, l’objectif pour nous était de recueillir les perceptions de chacun sur ce qu’est un système simple, comment on y parvient, ou inversement comment faire avec de la complexité.

Je vous invite donc à continuer le débat dans les commentaires.

Qu’est ce que cela vous inspire :

  • une expérience ?
  • un article qui résume votre avis ?
  • une conviction que vous vous êtes forgé ?
  • une citation ?
  • une image en base64 ?

5 commentaires sur “Pourquoi faire simple quand on peut faire compliqué ? – Extrait d’une discussion chez OCTO”

  • Toujours aussi riche et intéréssant !
  • Aaaarg, ça me manque les discussions technico-philosophiques de chez octo. J'ai retrouvé ça nulle part ailleurs. Y'a un autre ennemi de la simplicité c'est le biais de proportionnalité. Dans mon nouveau métier je regarde l'impact financier|marketing|produit de trucs divers et variés comme les refontes, les bugs, les pricings, les textes des tunnels etc… et franchement ça apprend l'humilité. On voit à quel point il n'y a aucune corrélation entre l'effort qu'on met dans quelque chose et l'impact que ça va avoir sur le confort des utilisateurs ou sur le CA. Un mot pas clair corrigé sur le site ou le produit peut avoir plus d'impact qu'une feature sur laquelle on a travaillé 4 mois. Un bug fix tout moisi peut avoir plus d'impact sur le CA qu'une refonte sur laquelle on a travaillé 1an… Mais quand on arrive avec une solution simple à un gros pb, effectivement, on a parfois plus de mal à la faire passer que si on propose "une refonte totale de X". C'est pas que pour des raisons politiques, l'être humain a du mal à accepter qu'une solution simple puisse exister à un pb complexe. On le voit avec le covid. Après, c'est là aussi la différence entre une startup et une boite plus grosse. Dans une startup ce biais existe moins en général et tes solutions simples sont accueillies à bras ouverts. Un autre problème aussi (je risque de me faire taper pour cette phrase) c'est qu'on considère le "working software" comme un asset. J'aime bien la vision de Bob Marshall sur le sujet (https://flowchainsensei.wordpress.com/2014/12/03/the-antimatter-manifesto/) : l'asset, c'est le service rendu à l'utilisateur et le working software c'est une dette. Si tu regardes les choses comme ça, les solutions simples deviennent plus faciles à rationaliser : tu gardes le même asset mais en diminuant tes coûts. 283 roupies indonésiennes
  • Merci Nicolas d'avoir partagé aussi tes réflexions :) Je retrouve dans ton premier point un aspect sur l'expérience utilisateur, que la valeur ajoutée d'un software est dans l'amélioration de son expérience au quotidien. Et qu'il est plus facile dans nos organisations actuelles d'aller chercher un budget pour quelque chose de nouveau, plus ambitieux, au détriment de l'aspect précédent. Je ne suis pas sûr de voir le lien que tu fais avec le Covid. Sur le dernier, le lien avec la vision de Bob Marshall, je ne comprends pas trop le fait qu'il dise logiciel=endetté. Ce que je comprends et retiens de son article, c'est que le logiciel est une solution, mais ça ne doit pas être une finalité.
  • C'est vrai que j'ai pas été super clair. Le lien que je fais avec le covid c'est le biais de proportionnalité : on accepte difficilement qu'un pb aussi énorme ait une explication aussi simple (c'est un virus comme il en pop régulièrement dans l'histoire), on préfère penser que c'est un coup de bill gates pour nous injecter de force des compteurs linky (si j'ai bien compris). Inversement, difficile pour beaucoup de penser que la maladie est grave si il suffit de se laver les mains et mettre un masque pour régler le pb. Je pense qu'une bonne partie des comportements et décisions délirantes (des gens ou du gouvernement) s'explique juste avec ce biais. Et en entreprise c'est pareil, ce biais fait bcp de dégâts... N'hésites pas à partager d'autres tranches de mailing list interne comme ça, ça fait un article sympa et vivant
  • Merci pour le thread :). Je me retrouve dans toute la réflexion. Ce qui m'intéresse vraiment c'est : comment en tant que membre actif de la construction d'un SI on part avec toutes ces bonnes intentions et on dérive à des systèmes (trop)complexes car on s'empêche, le plus souvent, de revenir sur les choses parce qu'elles fonctionnent. C'est comme si "on" avait constamment le biais de se dire que l'IT est, après tout, un centre de coût et non une valeur pour l'entreprise. :/ Je pense sincèrement au final que personne ne fait les choix pour les mauvaises raisons mais qu'elles sont étroitement liées au contexte et a l'environnent (Aka ADR tout ça). Au final être KISS pour moi revient à savoir s'adapter aux membres d'une équipe plus qu'à la technologie pour créer des systèmes qu'elle est en capacité de comprendre/maintenir et de-commissionner le temps venu. L'architecte est dans ce cas le chef d'orchestre de ces choix pour en faire quelque chose de puissant et agréable ;)
    1. Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha