Discussion :

[Michael Guilloux]

Trolldi : pourquoi coder lentement c'est coder plus vite
mais aucun développeur ne peut le faire dans la réalité

En tant que développeur, vous avez certainement déjà senti la nécessité de coder rapidement. Le plus souvent, cela se produit lorsque les délais sont très serrés et que vous sentez que vous ne serez pas en mesure de fournir un livrable attendu à temps. Mais parfois, ce comportement peut s’avérer très coûteux.

C’est le cas par exemple si la pression d’aller vite vous amène à sous-estimer le travail à faire ou à mal l’évaluer, ne pas respecter la conception, les règles de codage, etc. Une complexité cachée découverte plus tard vous conduit alors à revenir en arrière. Ainsi, la volonté d'aller plus vite vous aura tout simplement fait prendre du retard.

À l'inverse, vous arrivez à terminer le projet dans les délais, mais avec une forte dette technique. Il faut en effet rappeler que dans un projet, la qualité augmente la charge de travail, ce qui peut avoir un impact sur le délai immédiat. Ainsi, lors de la survenue imminente d'une nouvelle version d'un logiciel par exemple, respecter la conception idéale peut mettre en péril la livraison d'une nouvelle version du logiciel. À ce moment précis, ne pas respecter la conception idéale peut permettre d'atteindre l'objectif prioritaire à court terme (sortir une nouvelle version), mais vous contractez une dette technique que vous allez rembourser tout au long de la vie du produit sous forme de temps de développement de plus en plus long et de bogues de plus en plus fréquents.

La solution serait donc d’aller lentement mais sûrement ? Une chose est sure, cela va permettre d’éviter les pièges ou limiter les erreurs. Dans un billet de blog sur Programmerfu.com, Garrett Lancaster, créateur d'une application SaaS, essaie d'ailleurs d'expliquer qu'en programmation, « aller lentement, c'est aller plus vite », ce que beaucoup d'entre nous ne mettront peut-être pas en doute. Il faut donc « ralentir pour être un programmeur meilleur et plus heureux », a-t-il suggéré dans une discussion sur Reddit.

Il explique que cela ne sera pas seulement bénéfique pour le développeur lui-même, mais aussi pour les autres développeurs qui auront à travailler sur son code, que ça soit pour ajouter de nouvelles fonctionnalités ou pour le maintenir. Il n’est en effet pas nécessaire de rappeler comment cela peut être pénible de travailler sur un code de mauvaise qualité, et en plus écrit par une autre personne. Mais dans la réalité, vu les contraintes extérieures, la suggestion de Garrett Lancaster est-elle applicable ? Cela s'aligne-t-il avec la vision de l’entreprise et du management ? C'est sur ce point que la suggestion de Garrett Lancaster a été débattue.

Le fait est que le plus souvent, c’est l’entreprise et le management qui créent un environnement sous pression avec des délais très serrés obligeant les équipes de développeurs à essayer d’aller le plus vite possible. Il faut donc avant tout les persuader que cette manière de travailler peut affecter la qualité du code et pourrait nécessiter plus de travail plus tard. Pour un développeur qui essaie d’aller lentement pour éviter de commettre des erreurs graves, comment sera-t-il perçu par son manager ou son entreprise ? Comme quelqu’un de paresseux, sous-performant, non motivé ?

Et vous ?

Qu'en pensez-vous ?

[pierreact]

Informatique: On a le temps de faire mal 3 fois mais on a pas le temps de faire bien 1 fois.

[MikeRowSoft]

Moi qui ai toujours cru que je codais lentement vis-à-vis des perfs des autres...
Un bon RAD (plein d'affinités et intuitifs) et voilà que les choses changes.

Durée de vie du RAD estimé a combien d'année sur le marché du travail ?

(Windev, RAD Studio, ...) C'est bien sa le problème de la demande... Le second n'y est vraiment pas souvent, alors ses ancêtres...

[Cincinnatus]

Il ne s'agit pas de coder lentement, même si Garrett Lancaster parle de "taper lentement". Il s'agit d'abord de ne pas se précipiter, et comme il l'écrit également, de rassembler un maximum d'informations avant de planifier et se concentrer (sans interruptions extérieures).
En fait, réfléchir avant d'agir.
Effectivement, c'est parfois possible, mais pas dans tous les environnements de travail, malheureusement.

C'est cependant du bon sens, que je rapprocherais de DDD : Domain-Driven Design : on étudie le problème en large et en travers avant de concevoir et avant de programmer. ça semble un peu contradictoire avec TDD par contre.

[Invité]

Je suis globalement d'accord avec le billet, mais je pense qu'il manque une variable essentielle : quel est le surcoût de la qualité ?

S'il est exagéré (procédures délirantes), alors oui, les développeurs seront tentés de s'en passer pour gagner du temps.
Si on trouve un juste milieu, alors cela devient dérisoire. Sauf projet microscopique, quand on développe on passe plus de temps à réfléchir à comment coder les choses, comment les agencer, comment les afficher, comprendre le besoin utilisateur précis, qu'à écrire du code (propre ou non). C'est pour cela que la surcouche "qualité" peut devenir négligeable en temps : les normes de codage, l'organisation "intelligente" du code, les tests unitaires, les interfaces, les commentaires, la doc, ... tout cela n'est que du déroulage, lorsqu'on est un minimum rodé, et peut donc se faire rapidement.

[clorr]

D'accord avec Cincinnatus, il ne s'agit pas de coder "lentement" mais de ne pas se precipiter vers la 1e intuition venue et se retrouver dans une voie sans issue.

Après, il est difficile de trouver un compromis évident entre "se précipiter" et "prévoir tous les risques auxquels on pourrait être confronté", surtout que dans le 2e cas, on peut passer longtemps a ne rien faire et finir par se décourager.

Personnellement, j'essaie avant tout de modulariser l'application de manière a limiter la complexité unitaire de chaque module. Avec un bon découpage de modules et des contrats clairs entre modules, on peut se permettre de coder "vite fait, bien fait" à l'intérieur des modules car la dette technique restera circonscrite et facilement addressable par la suite

[MikeRowSoft]

C'est un peu la notion de culture générale en matière d'algorithmique, selon les précédents commentaires.
Pas faux aussi... Utilisation de framework et librairies tierces ou pas étant là encore ce qui peut faire la différence...

[Orionos]

Les problématique sont différentes selon les outils utilisés. Par exemple, si on fait une faute de frappe et que le projet met 10 minutes à build, alors oui il vaut mieux bien se relire et pas taper sur le clavier comme un décérébré. Perso, en Delphi a peu près n'importe quoi compile en un claquement de doigt. A tel point que je compile parfois juste pour mettre le curseur la ou je m'étais arrêté au milieu d'une ligne

Pour ce qui est de l'organisation de son temps, j’essaie une "nouvelle" technique.
Pour ne pas partir à droite à gauche j'ai une feuille de route de mon dev. C'est simplement une liste des choses que je sais à l'avance que je vais devoir faire. Chaque élément de la liste occupe entre 5 minutes et 4 heures.
Après le but c'est de s'y tenir, dans l'ordre, et sans déborder.

Ça m'aide à rester concentrer, et à ne rien oublier.

[Songbird]

Pour ne pas partir à droite à gauche j'ai une feuille de route de mon dev. C'est simplement une liste des choses que je sais à l'avance que je vais devoir faire. Chaque élément de la liste occupe entre 5 minutes et 4 heures.
Après le but c'est de s'y tenir, dans l'ordre, et sans déborder.

Ça m'aide à rester concentrer, et à ne rien oublier.

Je fais à peu près la même chose. Soit je laisse ça sur une feuille, quand ce sont des petits projets personnels, soit j'intègre ma feuille de route directement dans mon bug tracker et je lis chaque issue à un ou plusieurs commits lorsque je commence à coder, pour les retrouver facilement par la suite.

Sinon pour noter les spécificités de son programme, il y a Cucumber qui a l'air d'être vraiment pratique. Je ne l'ai pas encore utilisé donc je ne connais pas ses limites, mais ça me tente bien.

[Excellion]

Massacrer le clavier, copier-coller. Massacrer le clavier, copier-coller. Copier-coller, copier-coller, copier-coller, massacrer le clavier...

Compiler.

Merde ça marche pas... 🤣

Patcher. Compiler. Patcher. Compiler. Publier.


"Alors, maintenant on va faire une petite modif. Rien, hein! Ça prendra 5 minutes. Il faut juste changer ça, et rajouter ça. Ho, et puis ça, finalement, ce n'est plus utile. C'est bon ? Je reviens dans 5 minutes...." 🤣

[CodeurPlusPlus]

Il ne faut coder ni trop vite ni trop lentement, réfléchir suffisamment sans devenir contre-productif, et se rappeler que, quoi que l'on fasse, il y a toujours quelqu'un qui code à la fois plus vite et mieux que soi.

Voilà, j'ai fait plaisir à tout le monde en énumérant des banalités ?

[Matthieu Vergne]

Je suis croyant pratiquant du "rien ne sert de courir, il faut partir à point".

Je considère que du code doit, in fine, toujours être bien fait. Si urgence il y a, il faut le faire vite en prévoyant d'y revenir nécessairement plus tard, même si on pense l'avoir bien fait du premier coup. Il faut donc chiffrer le travail en partant du principe qu'on prendra le temps de le faire, puis y ajouter les frais supplémentaires pour fournir une version vite fait d'abord. Voilà comment je le conçois : soit c'est bien fait, soit c'est d'abord vite fait puis bien fait.

[foetus]

"se précipiter" et "prévoir tous les risques auxquels on pourrait être confronté"

Moi, je donne un autre son de cloche , ... mais dans un contexte de programmation tout seul (ou peut-être une toute petite équipe) - sans cahier de charges (ou presque rien)

Si je code lentement, c'est parce que je développe en "eXtrem Programming"

Je commence par intégrer des fonctionnalités en [ultra] simplifié. Ceci permet 0) de les coder rapidemment 1) d'intégrer d'autres fonctionnalités qui en dépendent 2) de tester cette fonctionnalité
Et ensuite ces fonctionnalités sont de plus en plus améliorés/ augmentées et refactorisées (*) et donc de plus en plus testées (et aussi de tester les dépendances).
C'est cela qui prend du temps: de coder en incrémental.

Et si ton code est bien modularisé, tu modifies à chaque fois que la partie nécessaire.
Et si tu dois supprimer du code, le temps passé sur les fonctionnalités supprimées dépend de leurs avancements.
Parce qu'on ne peut pas prévoir tout à l'avance. Donc on code minimaliste et si cela ne plait pas, ne sert à rien: placard ou poubelle.

Et ceci permet aussi de prendre de petites pauses (1 ou 2 jours par exemple), pour s'arrêter et réfléchir. Et éventuellement coder/ corriger 2-3 petits trucs. (<- tu avances toujours)
Il y a aussi l'ordre qui est important. On code les fonctionnalités ou on modifie les choses évidentes/ certaines/ prioritaires (<- les petites pauses permettent aussi d'évaluer l'avancement et de réajuster le pseudo-planning)

* le refactoring 1) prend le plus de temps 2) est nécessaire parce qu'on a toujours des fonctionnalités qui collent au mieux les besoins déjà codés, mais pas plus.
Son problème, c'est que souvent ton code ne fonctionne plus tant qu'il n'est pas fini (et donc tu n'as plus rien à montrer)

[Damoy]

Je ne suis pas vraiment d'accord, en faisant des erreurs, on apprend, et en apprenant les fois prochaines on sera beaucoup plus efficace, coder lentement c'est perdre son temps, à moins que ce qu'on est en train de faire / utiliser on ne le refera jamais ..

[Matthieu Vergne]

Coder lentement ne veut pas dire ne pas faire d'erreur. D'ailleurs, il ne s'agit pas simplement de coder lentement ou rapidement, qui ne veut rien dire en soit, mais de choisir entre prendre le temps de concevoir complètement avant de coder ou de se lancer dans le code tout de suite en concevant la solution à la volée. Les erreurs sont toujours possibles, dans les deux cas, mais la seconde pratique tant à faire du code qui sera jeté plus tard. Si le projet dure longtemps, les dépendances à ce code jetable s'agrémentant, il finira par devenir à la fois nécessaire à jeter mais impossible à jeter, mettant l'équipe dans l'embarras car il faudra non seulement refaire ce bout là mais aussi tous ceux qui en dépendent, et ainsi de suite.

[Pyramidev]

Si je code lentement, c'est parce que je développe en "eXtrem Programming"

L'eXtreme Programming se base sur les principes suivants :

• Le développement itératif. C'est ce que tu viens de décrire dans ton message.
• Le développement piloté par les tests (Test Driven Development) : on écrit les tests unitaires d'abord et on code la fonctionnalité ensuite. A court terme, c'est plus long que ne pas écrire de tests unitaires. A long terme, on détecte vite les régressions.
• Le binômage (pair programming) : deux développeurs par PC ! Il y en a un qui code et l'autre qui surveille les erreurs et propose des alternatives.
• Les binômes changent régulièrement de façon à ce que tout le monde connaisse un peu tout le programme. Ainsi, lors d'une itération, si la plupart des demandes se concentrent sur la même portion du programme, au lieu que seul le spécialiste de cette portion travaille dessus, une plus grosse partie de l'équipe peut intervenir.

C'est étrange que ton message focalise la lenteur à court terme sur le développement itératif alors que c'est surtout le binômage qui ralentit le plus à court terme. Développes-tu vraiment en eXtrem Programming ?

en faisant des erreurs, on apprend, et en apprenant les fois prochaines on sera beaucoup plus efficace, coder lentement c'est perdre son temps

Dans le contexte de l'article, l'expression coder lentement est trompeuse car, sémantiquement, elle suggère qu'il s'agit de réaliser les même tâches que coder rapidement, de manière moins rapide et plus soigneuse, alors qu'il s'agit en fait de réaliser plus de tâches.

Pour ajouter des fonctionnalités à un programme, un développeur qui travaille correctement ne fait pas que coder ce qui sera visible le jour de la livraison, et il ne fait pas que coder tout court. En effet, il faut penser aux tâches suivantes (la liste n'est pas exhaustive) :

• L'analyse du besoin. Quand le supérieur demande d'ajouter une fonctionnalité qui semble étrange, il faut demander quel est le besoin derrière au lieu de répondre "OK." et de foncer tête baissée dans le code. Parce que peut-être qu'il faudrait coder autre chose voire même qu'il n'y a pas besoin de changer le code.
• La factorisation du code entre plusieurs applications. Au lieu que chaque équipe de développement réinvente la roue carrée dans son coin pour son projet à elle, il faut discuter entre équipes pour mettre du code en commun. Ainsi, quand on corrige un bogue ou quand on ajoute une fonctionnalité dans le code commun, c'est effectif chez tout le monde.
• La documentation. Cela permet d'éviter que, quand un développeur quitte la boîte, les connaissances indispensables au bon déroulement du projet disparaissent avec lui.
• Le traitement des erreurs. Par exemple, au lieu de supposer que tous les fichiers en entrée sont au bon format et laisser le programme crasher lamentablement quand le format est incorrect, il faut construire un message d'erreur avec l'adresse du fichier et en quoi son contenu est incorrect. De même, quand une sauvegarde échoue, il faut afficher un message d'erreur pour avertir qu'elle a échouée au lieu de laisser l'utilisateur croire que tout va bien puis appeler le help desk quelques jours plus tard.
• Le programme doit aussi écrire un fichier de log qui décrit les actions des utilisateurs et les erreurs détectées. C'est parfois indispensable pour analyser des problèmes quand un utilisateur appelle le help desk.
• Les tests unitaires. C'est pour détecter plus facilement les régressions.

Quand un développeur fait tout ce travail, la hiérarchie peut avoir l'impression qu'il "code lentement" dans le sens où le code est "fini" plus tard. Mais, en réalité, il code plus de choses (par exemple, il traite les erreurs) et il fait aussi du travail qui ne consiste pas à écrire du code (par exemple, il documente).
Dans certaines boîtes, pour la hiérarchie, un développeur qui "code vite" est en fait un développeur qui ne fait que la moitié du travail et laisse une grosse dette technique. Mais la hiérarchie a l'impression qu'il a fait tout le travail car elle ne voit pas tout le suite les conséquences de cette dette technique.

[MikeRowSoft]

Je suis croyant pratiquant du "rien ne sert de courir, il faut partir à point".

Ohhhhhh!!!!

Et moi, je suis croyant pratiquant du "rien ne sert de courir, tout vient à point qui sait attendre".

Je te raconte pas les embuches rencontrées...

Cela étant, les PMI-PME et plus grandes sociétés sont souvent celles qui n'en rencontre pas avant d'avoir vendu les produits aux clients...

[Matthieu Vergne]

Je suis aussi un croyant pratiquant du "tout vient à point à qui sait attendre". Le truc, c'est que ça ne dit pas "à qui attend" mais "à qui sait attendre". Il s'agit d'une patience raisonnée, pas d'attendre que les autres fassent le boulot à ta place. Il faut du temps pour que certaines choses bougent, ou que des opportunités se manifestent. Le tout étant de se focaliser sur ce qui augmente tes chances d'obtenir ces opportunités plutôt que d'essayer de forcer la main. Il y a une inertie dans tout, et ça aussi il faut en être conscient et l'exploiter.

[MikeRowSoft]

Il s'agit d'une patience raisonnée, pas d'attendre que les autres fassent le boulot à ta place.

Chef de projet et maitre du planning à respecter...
Le peu que je connais au sujet du génie logiciel (C.N.A.M., cours du cycle probatoire, diplôme d'ingénieur) permet même d'introduire une mesure comme TOEIC pour les niveaux de maitrise d'une langue...

Bien sûr, encore faut-il pouvoir garder le niveau suffisamment longtemps...

[MikeRowSoft]

Qu'en pensez-vous ?

Se qui n'est pas un trolldi, c'est justifier le fait de toujours avoir besoin de coder pour un développeur dans une entreprise.
De justifier d'une place permanente et non remplaçable.

Après les outils métier de la comptabilité, je vois bien les écoles et universités payer un abonnement mensuel pour leurs structures informatique...
Sans oublier tous les bulletins d'information (MAJ, UPGRADE, DOWNGRADE) qui vont avec.