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 :
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 ?
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.
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 3x5 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.
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.
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 :
"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:
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".
> 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.
