Pourquoi les développeur(euse)s codent avec le cul

Pourquoi les développeur(euse)s codent avec le cul

Tout le monde a déjà utilisé ses fesses pour pondre un bout d’algo. Même toi qui lis ce texte avec des yeux hostiles. L’amoureux des process et le premier artisan développeur de France : ton postérieur a été utilisé dans un programme. D’ailleurs beaucoup de logiciels sont en partie, ou totalement, codés avec le cul. Mais pourquoi ? Qu’est-ce qui fait que, tous ensemble, on s’est bien mis tous d’accord pour faire de la merde ? Aller aujourd’hui on enfile son masque à gaz et on essaye de comprendre les codebases les plus pourries du monde !



Cours Forest !

Alors j’ai tout de suite commencé à t’insulter dans cet article en t’accusant d’avoir utilisé tes fesses dans ta codebase et je m’en excuse. Mais c’est vrai! Pourquoi j’en suis si sûr ? Parce que je sais que tu as déjà rencontré une horreur qui s’appelle la deadline. La deadline elle est laide, mais au début ça va parce qu’elle est loin. Du coup ton projet au début c’est les neuf symphonies de Beethoven. Y’a des arcs-en-ciel, ça sent le jasmin et ça se touche en code review. Mais très vite l’horreur de la deadline se rapproche et dans la panique tu commences à ne plus utiliser ton clavier comme d’habitude. Tu la connais cette situation.

Tu commences à commenter les trigger de CI parce que t’as pas le temps pour les tests. Deux jours plus tard, tu sais pas comment c’est possible, t’es encore plus en retard. Là tu transpires fort et tu commences à ne plus respecter le Git Flow. Jean-Jean responsable des Process ne vient plus te voir, il transpire lui aussi à l’autre bout de l’open space ! Et BOOM ça y est tout le monde code avec le cul. Point de non retour à partir de là c’est l’autoroute du caca. Plus le temps passe dans cette situation, plus tu transpires fort, plus ça va se ressentir sur le code. Et c’est là que réside l’explication pour une très grosse partie des programmes, jeux, logiciels codés avec le cul. Des dévs stressé(e)s de façon maximum à qui on demande souvent l’impossible en termes de temps. Ils deviennent évidemment complètement barjos en fin de projet quand la deadline est déjà pour hier.





On se fout bien de la gueule des retards dans le milieu du bâtiment. Mais dans le milieu de la programmation on est quand même bien des champions. Ramener la coupe à la maison ! Au fur et à mesure qu’une entreprise évolue et expérimente des façons de faire ce genre de situation tend à disparaître. Mais pour ceux comme moi qui sont passés en début de carrière dans des jeunes entreprises, notamment des agences de communication -où justement on vend bien les choses- ça doit vous parler. Heureusement les choses s’améliorent, les idées d’itération ont fait leur chemin et de moins en moins de monde deal avec ce genre de situation. Ceci dit ça veut pas dire qu’il faut arrêter d’utiliser ses fesses.



Il faut parfois coder avec le cul

OK alors tu dois te dire que j’ai craqué, mais pas du tout. Coder comme un gros sale c’est parfois ce qu’il faut faire. Retiens tes insultes ho grand gourou du code quality et lis la suite. C’est super important d’être polyvalent en tant que programmeur. Savoir écrire très rapidement un code avec son cul peut être primordial pour la réussite de certains projets.

Ça peut être aussi important que d’écrire du code parfait avec un peu plus de temps. Si tu bloques complet comme un végétarien devant une côte de bœuf, ça prouve un manque d’adaptation. Alors oui, tu vas me dire qu’avec une bonne gestion de projet et un process au top rien de tout ça arrive. Tu seras pas choqué d’apprendre que dans la vraie vie ça se passe pas comme sur ton diagramme de Gantt.

Dans la vraie vie ton patron il veut un PoC. Un proof of concept, une démo, un prototype tu l’appelles comme tu veux. En gros il veut que tu lui pondes un truc très rapidement pour prouver qu’il y’a du potentiel dans l’idée. Avec la bouse que tu lui auras chiée, il pourra alors te débloquer du temps pour ensuite faire le projet en vrai. Propre, avec la dernière techno dedans, comme tu aimes et tout. Et c’est OK de faire ça du coup. Il faut aussi comprendre que les gens ont besoin de preuve de faisabilité avant d’investir un maximum de thunes dans le projet sexy que tu veux faire. Bref du coup tu le lances dans la création du proto.

Tu fais ça vite et ça marche ! T’es content, t’es au top de ta vie. Tu vas pouvoir faire le chemin vers la bonne version qui partira en prod un jour. Mais parfois il se passe quelque chose de grave à la place. Ton patron il te regarde droit dans les yeux. Il tremble pas hein. Il te dit : “C’est super ce que t’as fait, on pousse en prod !” .





Trahison d’état. Prison ferme. La pire des décisions possibles. Le nombre de projets informatiques que j’ai vu avec ce scénario tourner en prod est hallucinant. Je suis sûr que c’est l’une des plus grandes raisons des codebases de merde. Les prototypes avec du code temporaire propulsé directement en prod sont légion dans les applis que tu utilises tous les jours. Un code de merde doit servir un but précis et être jeté une fois qu’il a rempli son but. C’est du code poubelle, un temps limité, qu’il faut détruire au lance-flamme dès que possible. Même du code normal a un temps limité alors t’imagines bien que celui-là ne devrait pas survivre. Souvent j’entends des responsables dire que c’est juste de la dette technique et qu’on finira par la rattraper. Non mais ça c’est du génie tellement c’est l’excuse parfaite.



Dette technique : le crime parfait

Je sais pas qui a inventé cette excuse, mais champion du monde lui aussi. Oui la gestion de la dette technique est une vraie pratique valide. Ici je parle des gens qui abusent de ce terme. Car une dette technique est censée être payée. C’est pas juste lancer trois buzz word d’un article que tu as lu un jour et oublié qu’il y’a des zombies au fin fond de ta codebase. La pratique du faisons vite on fixera plus tard est la troisième grande raison que ton app t’explose dans les mains quand tu l’utilises. Car le plus tard n’arrive jamais. Et sur ce point les développeur(euse)s eux-mêmes sont aussi coupables que les gestionnaires des projets IT.

Je parlais des protos en prod mais y’a pas que ça. La fameuse “gestion” de la dette technique ouvre la porte à toutes les fenêtres. Et certains malins s’engouffrent là-dedans en saut de l’ange. Ils appellent ça la dette volontaire. Quand une nouvelle fonctionnalité non prévue arrive en fin de projet qu’est-ce qui se passe ? BOOM sortez vos fesses les gars on va coder ça vite! Vous inquiétez pas c’est de la dette volontaire on rattrapera ça vite. Quelques semaines plus tard, quand il faut justement nettoyer, les priorités ont changées ! Et tu te retrouves à ajouter une feature dans du spaghetti code en détestant ta vie. Tu te demandes comment t’en es arrivé là et si le problème aurait pu être géré en amont.





C’est un pattern qui revient très souvent dans un cas de spaghetti code de l’enfer dans ton app : le mauvais design. Et là je reviens sur la comparaison avec le milieu du bâtiment. Si les fondations ne sont pas solides ton bâtiment ça va être de la merde. Il risque de se péter la gueule et comme t’es à l’intérieur tu vas pas kiffer. En informatique c’est pareil. La qualité du design en amont est critique pour le futur code de ton application. Il suffit qu’il y ait une couille dans le potager et le dev va commencer à faire des hacks pour rattraper l’oubli dans les specs. Plus y’en aura et plus il va commencer à mettre de la merde partout pour faire tenir les murs. Et en un rien de temps ton projet est tout moisi et ton développeur démotivé.



C’est aussi la faute aux développeur(euse)s ?

Dans le grand schéma des choses, la plupart des cas avérés de gros caca dans le code sont le fait de gestion de projets désastreuse. Maintenant qu’on a bien insisté là-dessus, je suis obligé de dire que parfois le problème vient aussi des développeur(euse)s. Il y a des développeurs non motivés. Des gens qui sont là pour faire de la thunase et qui en ont rien à foutre du code. Ils en ont rien à foutre de toi et de tes efforts pour faire une code base potable. Ils se foutent encore plus du produit et de sa pérennité. Et t’imagines même pas l’intérêt qu’ils ont pour la boite où ils sont! Des touristes qui ont zéro autonomie sur aucune tâche. Oui un dev non motivé avec aucun investissement contribue à ce que ton programme plante tout le temps. Mais ça représente une faible part des raisons. Une personne comme ça se fait souvent dégager assez vite ou part d’elle-même. La plupart du temps, pas tout le temps. À leur départ ces personnes sont très souvent remplacées par des juniors.





Des juniors qui sont propulsés dans un projet comme des petits singes dans la dernière fusée d’Elon Musk. Allez le jeune t’es payé comme une merde mais tu vas nous faire un boulot de senior. T’inquiète pas, t’es un champion, t’es une vraie rockstar ! Sauf que le junior c’est un junior. Il peut pas être au niveau d’un senior parce que le projet le demande. Une phrase aussi simple est pas comprise par beaucoup de monde. Et du coup ça entre dans les raisons pour laquelle ton site il marche pas. La mauvaise personne a été obligée de bosser sur ton site et tu te retrouves à courir sur un lac gelé en claquette pour tout rattraper. Fatalement ça peut pas marcher. Surtout que, non seulement on te met un junior, mais en plus on le forme pas !





Faire du bon code c’est pas un don naturel donné en mode loterie à la naissance. Faire du bon code ça s’apprend. Il y a des façons de faire, des façons de penser, d’aborder les problèmes. Il y a un milliard de choses à savoir qui -ensemble- vont te permettre de faire un code de qualité. Avec des process de qualité type test coverage, pipeline, code review et pair-programming on s’approche un peu plus de la qualité. Le problème c’est que c’est du luxe. Ça coute cher de faire tout ça, ça prend du temps. Du temps que la plupart des boites n’ont pas. Beaucoup des logiciels que tu utilises sont pourris parce que c’est trop cher la qualité. C’est pas toutes les boites qui ont les moyens de prendre le temps et de mettre des moyens dans ta formation et tes projets.



Épilogue

Si tout ce que tu utilises se pète la gueule à la seconde où tu cliques dessus c’est parce que c’est des gens en panique qui ont bossé dessus. Dans un monde parfait la gestion de projet est prévoyante et les développeur(euse)s sont autant motivé(e)s que formé(e)s. Mais la vie c’est de la merde et à la fin on meurt. En attendant si vous trouvez une boite qui donne vraiment de l’importance à la qualité en dehors des buzz word : restez-y. Vous avez trouvé une licorne et elles sont vraiment rares.

Qui me parle ?

jesuisundev
Je suis un dev. En ce moment je suis Backend Développeur / DevOps à Ubisoft. Je suis passionné du dev et j'écris comme je parle. Je continue à te parler quotidiennement sur mon Twitter. Tu peux m'insulter à cette e-mail ou le faire directement dans les commentaires juste en dessous. Y'a même une newsletter !

Commentaire(s)

    1. Pour compléter la remarque de Corentin: au-dela des callbacks dans les callbacks, en général dès que l’on dépasse 2 ou 3 niveaux d’imbrications, c’est qu’il est temps de revoir sa copie (découper en sous-fonctions, utiliser des patterns, …)

    2. ça s’appelle une pyramid of doom. C’est quand une grande quantité d’instructions successives nécessitent d’entrer dans un block. Comme l’ouverture d’un block implique un nouveau degré d’indentation puis finit par se désindenter cela forme une pyramide.
      Le cas arrive non seulement pour les callbacks mais aussi pour les enchaînements de conditions, une solution pour éviter de surindenter serait d’inverser les conditions et de retourner quand une condition se vérifie.

  1. ahah le POC poussé en prod ou qui sert de base au projet, un classique!! S’ils pouvaient se projeter dans le futur, les responsables qui prennent ce type de décision y renonceraient immédiatement…
    Par contre, en province, j’ai constaté que l’attente en termes de qualité vis à vis des juniors est parfois simplement lié au fait qu’ils se vendent à prix d’or.. à demander des salaires proches de ceux des seniors, on attend parfois d’eux le même niveau (ce qui est une aberration j’en conviens..).

  2. On ne peut qu’être d’accord avec tout ce qui est dit …
    Ce que j’aimerais savoir en revanche c’est si il y a des études sur le coût réel de la dette technique et du code de merde : combien ça coûte à une entreprise de traîner ça pendant des mois, voire des années, les coûts de maintenance, le fait que le framework est complètement dépassé et que toute modifications prend des lustres au regard de technos plus modernes. Une étude qui estimerait le coût si les choses avaient correctement été faites en comparaison avec le coût réel. On s’apercevrait peut-être que la qualité ne coûtent pas cher, ce qui pourrait motiver les décideurs (ceux qui ne comprennent pas ce qu’incombe le développement informatique) à donner les moyens aux équipes de bien faire …

    1. Je suis pas certain. Mais je pense que tu peux trouver par contre dés études qui montre la faillit d’une entreprise du à du code coder avec le cul. (Il en parle déjà dans un des premiers chapitres de “Clean Code” de Clean Code
      Robert C. Martin)

    2. Désolé mec mais c’est exactement mesuré et décrit dans “The Economics of Software Quality” depuis un petit moment. Le seul pélo (= Capers Jones) qui s’est penché sur la qualité des codebases de manière statistique a découvert… que comme notre intuition indique, la qualité à un cout négatif pour les projets logiciels.

      Prévoir d’avoir une haute qualité non seulement réduit les délais, mais rend les logiciels plus rentables, diminue les abandons, les dépassement de budgets et les procès.
      Et c’est chiffré noir sur blanc dans son bouquin http://ptgmedia.pearsoncmg.com/images/9780132582209/samplepages/0132582201.pdf

      C’est pas parce que le monde marche de manière pourrie qu’on ne connait pas exactement la solution du problème. Mais pour ça il faudrait des gens qui s’intéressent au fondamentaux et envisagent d’ouvrir un livre sur la question.

    3. Sans pouvoir détailler vraiment via une étude de la dette technique, l’article de dvp.net est pas mal :
      “D’après l’étude, si les équipes IT passent 50 % de leur temps à coder de nouvelles applications et améliorations, elles prennent environ 40 % du temps consacré au développement pour gérer la dette technique.”

      https://www.developpez.com/actu/228268/Etude-50-pourcent-des-projets-de-developpement-d-applications-se-soldent-par-un-echec-cela-est-il-du-a-la-lenteur-des-codeurs-et-la-dette-technique/

  3. En tant que freelance, devinez ce qu’on nous demande le plus souvent ? (Quand on a pas le luxe de choisir ses projets…)
    De faire le pompier sur le projet que le précédent freelance pas motivé (normal vu le tjm) a planté 3 semaines avant la deadline.
    Et ben, on code avec le cul et on pleure sous la douche…

    1. t es gentille en disant pompier. Je trouve qu on vous considère plus comme des putes perso. mais c est un peu ce que vous etes au final en France, une ressource qui va, sur un projet sans aucune valeur, taper du code pour une ssii. Sils pouvaient faire coder une chèvre, tu ne serais plus la.

    2. Oui c’est tout à fait ça ! Je suis sur une mission en ce moment et une partie de mon job est de rattraper les erreurs faites par un précédent dev (faut voir le désastre…).

      1. Je ne sais pas si c’est la raison, mais les développeuses que je connais sont meilleures, en moyenne, que les développeurs. (en moyenne, hein, l’écart type est brutal dans les deux catégories).

        1. Ça n’a rien avoir avec le fait d’être bon ou pas. Je suis developpeuse, on se plaint pas souvent de mon code et pourtant il m’est arrivé (rarement heureusement) de coder avec le cul par obligation 😁

        2. Pour le coup le sexe importe peu, je sais pas pourquoi le fait d’avoir un vagin implique qu’une dév est meilleure (ou moins bonne) que les hommes. Perso je trouve que c’est réparti de la même manière et qu’il y a autant de tocardes chez les meufs en proportion que de brêles chez les mecs 😀

        1. N’est illisible l’écriture inclusive qui ne t’es pas habituelle, tu passes tous les jours a coté de plein d’autres écritures inclusives auquel tu ne fais absolument pas attention car tu as l’habitude de les voir.
          Faut pas oublier qu’on écrivait comme ca avant et ca ne posait aucun soucis a personne, c’est plus “récent” le fait de moins écrire en langage épicène.

  4. Il faut pas non plus se mettre la tête au court bouillon tout le temps.
    Clairement, plein de bonnes pratiques sont à revoir, mais certaines choses sont moins grave que d’autre.
    Typiquement le bout de code sur les callbacks. Clairement, je vais dès le départ utiliser des promesses ou tout autre outillage que les technos employés me permet, ou p-e mème que je coderai la mécanique à la main, c’est pas bien méchant. M’enfin, si je vois ca sur un code de quelqu’un d’autre (je gère une mini équipe), bah j’en fais pas tout un drame, ca reste lisible, et peu de chance de bug, il y a pas de logique la dedans.
    Le maitre mot ici est la lisibilité.
    On vois trop souvent des codes en Python ou en js ou je ne sais quoi d’autre qui se veulent magnifique parce qu’il font pas mal de choses en peu de ligne, mais on y bite rien la moitié du temps, c’est pas ça un code propre.
    Moi, j’essai de faire le ratio temps/gain. Parfois, ca ne me dérange pas de faire un truc rapidos, je me met un TODO, et j’y reviens plus tard. Parce qu’à un moment donné, faut aller vite, et que faire parfait, bah ca prend parfois 3 fois plus de temps pour un gain quasi négligeable.
    Alors ok, pour les bonnes pratiques, maintenant les devs qui nous bourrent le mou avec leur bonne pratique et qui finissent jamais un projet, ou qui ne sont pas capable de tester leur code, bah non merci.

  5. Je vois une autre bonne raison de coder salement (mais c’est peut-être une théorie du complot) : le gros plat de spaghettis fait intentionnellement pour te décourager de forker un bidule open-source gratuit de base mais proposé en premium avec plus d’options.

    Là je suis en train de m’arracher les tifs sur plugin WordPress qu’on ne citera pas avec :

    – Des feuilles de style du plugin avec des !important partout qui t’obligent soit à surcharger comme un porc quand tu veux changer la couleur d’un bouton, soit carrément à dégager ces feuilles de style et tout reprendre à zéro.

    – Des templates constitués de hooks qui appellent d’autres hooks qui appellent d’autres hooks… qui appellent des fonctions qui te retournent du html !

    – Une doc périmée et balancée en vrac sur le site.

    Bref le genre de plugins que tu installes parce qu’il cochait toutes les cases des fonctionnalités requises…mais au final que tu aurais mieux fait de coder toi-même vu comment il t’a pris la tête pour changer un micro px de poil de cul sur ton menu déroulant !

  6. Cet article a illuminé ma journée et on ne peut que s’y retrouver, je viens d’ailleurs de terminer un projet madeWithPopotin() parce que je n’ai pas pu faire autrement… #vdm

  7. Je ne compte même plus le nombre de fois où je me suis embrouillé avec des autres développeurs de l’équipe pour faire de la qualité du code même quand il faut implémenter une feature rapidement. Et effectivement, il y a beaucoup trop de développeurs qui pondent de la merde même quand la deadline est loin car c’est comme ça qu’ils codent.
    Malheureusement en France, on est trop peu regardant sur la qualité et beaucoup trop de projets entrainent a de très mauvaises pratiques si bien que développeurs dit Senior développent aussi mal qu’un junior

    1. Malheureusement en France, on est trop peu regardant sur la qualité et beaucoup trop de projets entrainent a de très mauvaises pratiques si bien que développeurs dit Senior développent aussi mal qu’un junior

      Dans mon cas (et dans de nombreux autres j’imagine), c’est pire : ce sont les développeurs séniors de la boîte où j’étais qui me disaient que mes bonnes pratiques ne servaient à rien et qui m’ont revoir mes exigeances à la baisse (pendant un temps seulement, heureusement).

    2. ça fait plusieurs années que je bosse avec d’autres nationalités que des français, retire immédiatement ce cliché de gilet-jauniste et va faire un stage non rémunéré à Bengalore stp.

    3. I’l m’est arrivé(pas assez souvent), du temps ou j’étais développeur, de dire “allez vous faire foutre, je vais faire ça proprement”. Et bizarrement, à chaque fois que j’ai fait proprement, j’ai quand même fini dans les temps, ou presque.

      Je ne crois pas que ça soit un hasard. Même du code jetable(i.e. à usage unique), si on le conçoit d’entrée dans sa globalité, ira plus vite jusqu’au stade ou il est bon.

  8. Conclusion, simple, basique, il suffit de supprimer les “deadlines”. La seule responsabilité des développeurs devient: créer un code qui a le meilleur rapport temps de développement/maintenabilité et prouver que les pratiques utilisées sont les plus efficaces. Le comité de pilotage donne la direction que les développements doivent prendre pour créer le maximum de valeur en un minimum de temps, et réajuste dès que la valeur produite n’est pas à la hauteur de l’effort investit. Il n’y a plus de développeurs qui s’engagent sur une estimation à long terme et cachent les difficultés le plus longtemps possible jusqu’à l’explosion du projet contre la deadline. Il n’y a que des développeurs qui deviennent experts pour identifier, communiquer et apprendre des difficultés rencontrées. Cela évite que ces difficultés aient un impact dévastateur. Les développeurs utilisent toujours la notion de temps, sous forme de “timebox” (ex: 1 semaine) pour évaluer une direction choisi. Mais à la fin de la “timebox”, les développeurs sont gratifiés de la même manière, qu’ils démontrent que la direction était la bonne en implémentant une solution, ou qu’ils démontrent le contraire en mettent en évidence de nouvelles difficultés avec une analyse suffisamment riche pour permettre d’adapter la direction choisi.

    L’entreprise où je travaille applique cette stratégie. Dans mon cas les développeurs et le comité de pilotage ne font qu’un. La valeur produite me semble deux fois supérieurs aux entreprises que j’ai connu précédemment (7 en 20 ans). La plus grande différence: le temps passé en innovation qui est bien supérieur au temps passé en maintenance.

  9. Et aussi EL FAMOSO methode agile, le chef de projet : ” Bonjour, je veux que l’application fasse X, Y, permettant de faire voler un avion”
    Le développeur en 2 jours doit devenir un expert en aviation, apprendre de nouvelle techno en même temps, et si y a un truc qui fonctionne pas c’est parceque le développeur est une merde et pas parcequ’il y connait rien en aviation LOL

T'en penses quoi ?

Your email address will not be published. Required fields are marked *