Le code de qualité coûte-t-il plus cher ? - Arène Artisan Développeur

Connexion

Télécharge les 3 arguments Godwin pour convaincre ton boss !

Oui31 %

69 %Non

Le code de qualité coûte-t-il plus cher ?

La bataille est terminée !

Cette bataille est terminée ! Merci à tous les participants !Voir les autres batailles

Non
Non ! La manière la plus rapide de faire les choses est le "bonne" manière de faire les choses. On le paie plus tard... Et en fait, on va juste plus vite quand on fait les choses bien. On vit dans l'illusion de l'instant présent, on se dit qu'on va plus vite en prenant un raccourci, mais ça ne dure que 5 minutes, et encore. Après avoir codé trois fois l'algorithme en prenant divers raccourcis, on est bien obligé de se remettre à la réalité : dès le début on aurait dû commencer par la version propre et complète, sans bidouille. Et au final on a juste perdu du temps à essayer d'aller plus vite...

Un développeur qui pense comme ça, c'est le signe d'une certaine séniorité : il s'est cassé le nez suffisamment de fois pour le savoir et a assez de recul pour l'avoir appris.

jplambert

Oui
Qu'est ce qu'un code de qualité ?

On admettra que pour qu'un code soit de qualité, il faut savoir. Donc il est passé par une phase de code review (logique, architecture, respect des normes, des best practice...) et de QA (pour en valider le bon fonctionnement dans tous les cas attendus).

Il est donc déjà à priori déjà plus cher puisque pour savoir qu'il est de qualité d'autres personnes ont du passer dessus.

Actuellement le post avec le plus de non se termine par:

Un développeur qui pense comme ça, c'est le signe d'une certaine séniorité : il s'est cassé le nez suffisamment de fois pour le savoir et a assez de recul pour l'avoir appris.

Ce qui veut dire travailler avec des gens expérimentés qu'on paie fatalement plus chère.

Méditez cette phrase que toute personne participé un jour à un projet connaît.

On sait faire des choses vites.
On sait faire des choses biens.
On sait faire des choses pas chères.
Mais on ne sait faire que deux choses à la fois.

yturenne

Non
A moyen et long terme, non. Le code de qualité sera plus facile à maintenir, et on évite l'effet "refonte complète tous les deux ans"

didier

Oui
Oui mais il faut le voir comme un investissement. Ça dépend de la durée de vie du produit ;)

julien-2

Non
Biensûre que non, je prêche en convaincu, le fait de développer en tant qu'artisant logiciel. Un code de qualité commence déjà dans la compréhension du métier par des pratiques comme le DDD, puis la pratique du Outside-In TDD (ATDD ou BDD + TDD) en pair programming. Mes plus:
- moins d'aller-retour avec le métier pour comprendre son besoin -> bug de compréhension du besoin fortememnt limiter
- mon code est continuellement verifier par les test dans mon CI -> Feedback rapide, d'ou correction peut couteuse
- Je peux ajouter une fonctionalité sans avoir peur d'en casser une autre, je suis protéger par les tests
- J'ai un bug, j'écris un test et je trouve rapidement la source de mon problème

Serieusement sans cette discipline, je devrais passer une bonne partie de mon temps a debugger au lieu d'ajouter de la valeur.

Un test rapide, prennez notes pendant une itération de travail, le temps que vous passez a coder de la valeur et combien a debugger.

alexandre-cuva

Oui
Un développeur de qualité coûte plus cher donc du code de qualité coûte plus cher.
Même s'il peut y avoir des exceptions dans l'ensemble je pense qu'un dev expérimenté fera du code de meilleure qualité, et en général un dev expérimenté demande un plus gros salaire qu'un débutant sorti d'école.
Même si sur le long terme une partie du coût sera amorti par de moindres corrections, combien de projets vont vraiment survivre sur ce long terme sans avoir besoin d'être profondément transformés pour s'adapter à de nouvelles demandes ou pour intégrer une nouvelle techno à la mode ?

Non
Imaginez un artisan qui passerait 50% de son temps à chercher ses outils dans un atelier mal rangé. Question rentabilité, on peut faire mieux, y compris pour la santé mentale.

lama

Oui
Si on parle d’instant T, alors oui, ça coûte cher à l’instant T, mais par contre le coût pour le futur sera de plus en plus faible! (maintenance, ajout de fonctionnalité, éviter les reset des projets...)

abderrahim-benmakhlouf

Non
Avant de comparer l'approche "quick and dirty" et l'approche "soin accentué du code", il convient de mettre en avant une pré-condition cruciale :
- "L'énoncé est-il EXACTEMENT le même ?"
En quick and dirty, on a tendance à faire l'impasse sur les Wrong Paths (branches menant à des erreurs, tels que des crédits insuffisants pour un paiement, etc) et les subtilités d'une feature.
Dans ce mode, on va à l'essentiel, ce qui conduit à un développement qui semble répondre à l'énoncé, alors qu'en réalité il y répond ULTRA partiellement.
Sans parler tout de suite de qualité de code, est-ce professionnel de répondre partiellement à un énoncé ?
Réponse : non; c'est une approche déguisée d'un échec, en succès.

En mode "soin accentué du code", en général, je dis bien en général, on émerge par des raisonnements souvent poussés les sous-problématiques de l'énoncé : Les Wrong paths ET les subtilités de la feature.

Une fois cela connu de tous, je peux confirmer que :
- Pour un même énoncé, c'est-à-dire visant le même "perfectionnisme" de la feature à réaliser, un code léché sera toujours pondu plus rapidement qu'un code quick and dirty, à partir du moment où le développeur maîtrise la programmation et les méthodes (TDD, SOLID, etc), et ne bidouille pas, comme le font la plupart qui souhaitent du jour au lendemain faire de la "qualité".

Une approche léchée consiste en une approche 100% TDD, et à une qualité et rapidité de refactoring constante et irréprochable.
TDD permet avant tout de coder plus vite (et non de tester), mais pour vivre et SENTIR cela, il faut avoir un bagage technique conséquent.

C'est dur ...oh que oui, c'est bien pour cela que peu d'équipes peuvent se vanter d'avoir le potentiel de produire de la qualité; malheureusement.

Ce genre de pratique (couplée à d'autres) permet de s'affranchir du mode debug, de s'affranchir d'ouvrir un navigateur avec des "console.log("yo")" pour deviner d'où vient ses problèmes de code.
Le temps gagné sans debug ni navigateur : AFFOLANT !; et sur le court terme, pas uniquement moyen et long terme.
TEMPS = ARGENT donc moins de temps = ECONOMIE.

Soyez-en sûrs, il existe des développeurs qui vous prouveront qu'un code léché va beaucoup plus vite qu'un code exécuté par l'instinct et un raisonnement "mono-branche"; "mono-branche" = sans prendre en compte les problèmes/énoncés sous-jacents à tous problèmes/énoncés."

Je peux vous assurer que j'ai économisé plus de 5 fois le budget qu'aurait prévu des pro-quick-and-dirty, à plusieurs clients qui pourraient en témoigner sans souci; et qui en avaient fait les frais par le passé.

The only way to go fast is to go well, et je le prouve lors de mes formations WealCome : wealcomecompany.com

mazerhad

Oui
Je vais mettre oui car le non va gagner, et que d'après moi, avec une question comme cela en l'air la réponse est "ça dépend".

En vérité j'aurai aimé mettre non, car un code mal fichu coutera toujours plus chère à maintenir et faire évoluer.

Mais pour un projet de POC? Pour une version alpha d'un produit innovant dont on souhaite estimer si le besoin existe réellement? Faut-il vraiment passer plus de temps (et donc d'argent) pour un produit qui au final ne sera peut-être pas exploité? Après c'est sûr, si le produit fonctionne cela va coûter plus chère que si cela avait été bien fait dès le départ. Mais encore une fois, certaines boites lancent 10 projets par mois et regarde si l'un d'eux prend. Et des fois il faut attendre 20 ou 30 projets avant de tomber sur un "produit" qui attire le consommateur. Avec de tels rations, il est peut-être bon de produire un code à faible coût (développé rapidement sans TDD, et dossier d'architecture) et quand le projet prend, faire un gros refacto dès le début.

Après pour un projet sur moyen / long terme, un code TDD de qualité dès le démarrage me parait être de toutes évidences moins couteux.

En conclusion, cela dépend du projet, des besoins, et de la durée de vie du projet ...

P.S : Certains grands industriels préfèrent avoir des systèmes redondant pour prendre le relais lors de dysfonctionnements plutôt que d'amélioré la qualité des softs. Preuve que dans certaines situations la qualité coûte plus chère que le gain apporté par cette même qualité.

franck

Non
Non. Car le code moche / naïf est in-maintenable. Le problème est quand on y reviendra dessus : eh bien le changement coûtera tellement plus cher ! C'est là où le code de qualité fera ses preuves : peut-être plus long à produire au début, mais bien moins cher sur le long terme !

bruyere-geoffrey

Oui
Qui dit qualité, dit patiente et endurance.
Un code qui fonctionne ne veut pas dire forcément un code de qualité. La qualité demande un investissement en temps, en ressource et en argent.
Choisir la qualité c'est se préparé à l'avenir pour faire face aux défis techniques.

ndiayemor86

Non
Ça dépend ¯\(ツ)/¯ ! (donc non)

Ça dépend si on veut que le produit dure dans le temps. Si on préfere un produit qui dure quelques mois, probablement qu'"investir" dans de la non qualité est bénéfique.

Maintenant, si on ne sait pas quand le produit doit terminer sa vie, ou si on préfère le faire durer le plus longtemps possible, alors il devient évident économiquement "d'investir" sur de la qualité.

Mais que veut dire "investir" sur de la qualité ?

jerome

Oui
Oui, le code de qualité coûte plus cher à l'achat, mais comme tout investissement qui sera amorti, cela coûte souvent moins cher sur la durée.

Il arrive également que certains raccourcis soient pris (dette technique) afin de pouvoir être rapidement sur un marché.
Cette dette devra être remboursée et aura forcément un coût, mais qui aura potentiellement permis d'y gagner financièrement.

sebastien-rabiller

Non
Pour moi tout développeur devrait répondre à une charte de qualité. Être garant de son code et être fier de ce qu’il a produit.
Étant free-lance je suis amené à reprendre le code de certains projets et j’ai l’impression que l’ancien développeur travaillait juste pour l’appât du gain parfois. J’ai aussi vu du très beau code à certains moments. Je n’en fais pas une généralité.
Je constate juste que certains devs ne prennent pas en compte le futur trafic que le site web peut générer. Lorsqu’ils font leur tests unitaires tout fonctionne mais une fois en Prod ça crash. Entre requêtes appelés x fois sans travailler en POO ou cache non pris en compte sur la prod ou front extrêmement lourd... on devrait créer une charte de bonne conduite :-)
Quand je lis qu’un code de qualité prend plus de temps je ne suis pas en phase. Tout code doit être réfléchit en amont. Avant même les premières lignes. Bien comprendre la demande client et la refuser si elle semble incomplète. La retravailler avec le client. Par contre un code de mauvaise qualité va prendre plus de temps. Surtout si vous devez le retravailler car : soit la demande évolue soit il y a des bugs lors de la recette client.
Pour moi tout code doit être clairement structuré et bien pensé dès le début.
Alors on signe ma charte ?? :-)

camao

Oui
I agree.
Because the developer how makes a robust, clean and quality code deliver less bugs.
Besides, he worked and learned a lot to deliver something like that so he deserves to be paid well.

ramibelgacem

Non
Je pense que même certains objets de la vie courante peuvent être de bonne qualité et coûter moins cher sur le long terme par rapport à un produit bas de gamme qui ne durera pas et qu'on devra racheter plusieurs fois. Le code de qualité coûte moins cher mais qu'il y a une condition pour que ce soit vrai: que les devs soient bons. Sinon il est fort probable que l'effort a fournir pour du code de qualité coûte bien plus cher.

emmanuel-riche

Oui
Ça dépend des qualités des développeurs tous simplement un développeur qui fait du spaghetti code et qui n'utilise pas des les designs patterns c'est moins cher mais 0 qualité petit exemple les freelancer de l'Inde

kacem-oussama

Non
Quand on pense que :
- Constater un bug (parfois présent depuis des mois en prod)
- Le tracer dans un outil dédié
- Investiguer pour trouver la source
- Le corriger sans tout casser (= poser une rustine)
- Relivrer en priant pour qu'il n'y ai pas eu de nouvelles régressions

c'est beaucoup trop long et beaucoup trop cher !

Le coût n'est pas que financier ! Avec tout ce stress le temps de vie de tous les collaborateurs est grandement réduit et ça c'est inestimable ! :D

antoine-benard

Oui
Sur le court terme, oui. Sur le long terme, moins de rework et de bugs, et donc probablement non. Mais vraiment difficile à évaluer je pense !

rodolphe-lemasquerier

Non
Il faudrait déjà définir ce qu'est un code de qualité avant de répondre à cette question...

Qu'est-ce qu'un code de bonne qualité ?
Pour moi, c'est un code qui respecte les propriétés suivantes :
- il fait ce qu'on attend de lui, ni plus, ni moins ;
- il ne contient pas de bug ;
- il est simple à lire ;
- il est simple à ré-utiliser.

Par contre, il est très compliqué à écrire (mais c'est pareil pour du code de mauvaise qualité).

Sans la bonne méthodologie, l'écriture du code coûte très cher, qu'il soit de bonne ou mauvaise qualité.

Personnellement, j'utilise TDD afin de produire du code de bonne qualité.

TDD me permet de respecter mon premier critère (il fait ce qu'on attend de lui, ni plus, ni moins). Je n'écris donc pas de fonctionnalité inutile (gain de temps à court terme) mais j'encadre parfaitement le cadre de mes fonctionnalités, ce qui fait que j'ai très peu de cas imprévu (gain de temps à long terme).

En répondant au premier critère, mon code ne fait que ce qui est attendu, il ne contient donc pas de bug (les seuls bugs que je produis sont des fonctionnalités sur lesquels je ne suis pas allé au bout et pour lesquels j'ai oublié un cas). Pas de bug signifie gain de temps à long terme.

- Pour ne pas citer Michael AZERHAD, l'une des conséquences heureuses de TDD est de mettre en place des tests. Ces tests permettent de pratiquer le refactoring en toute sécurité.

Le refactoring permet de simplifier le code pour qu'il soit simple à lire (troisième critère). Cela permet à d'autres développeurs (des collègues ou des clients) de s'approprier facilement le code, c'est donc un gain de temps.

Le refactoring permet aussi de rendre le code réutilisable. Il est plus rapide de réutiliser une fonction de bonne qualité (donc facile à réutiliser) qu'un copier-coller de mauvaise qualité. C'est donc aussi un gain de temps.

Ce qui coûte cher, ce n'est pas d'écrire du code de bonne qualité, c'est de ne pas utiliser la bonne méthodologie.

Et indépendament de la qualité du code, une autre chose qui coûte cher, c'est le temps nécessaire pour tester le code (qu'il soit bon ou mauvais). TDD implique des tests unitaires et les tests unitaires sont rapides. Là où un développeur sans TDD va mettre une minute pour tester un petit bout de la fonctionnalité qu'il est en train de développer (ça prend du temps de lancer l'IHM, de remettre à jour la BDD, de vérifier que les webservices sont en place), le développeur avec TDD mettra 3 secondes.

Donc, non seulement le code de qualité ne coute pas plus cher que le code de mauvaise qualité, mais il nous oblige à utiliser une méthodologie qui fait gagner du temps.

johjo

Oui
Un code de qualité c'est un code avec conception et test en plus de la réalisation seule. Et tout ca on le paie !

justin-rabiller

Non
Dans un certain contexte, une Lada peut s'avérer plus pertinente (donc de meilleure qualité ?). On peut supposer qu'elle résistera par exemple mieux au froid sibérien.
Une réponse facile serait de dire que sur le moyen et long terme on s'y retrouve très vite avec du code de qualité car plus facile à relire, mieux découpé, et bien sûr testé !
Mais en fait c'est bien plus tranché car même à court terme on s'y retrouve, penser au confort et la quiétude de vos développeurs, votre vendredi soir sans ruminer suite à une MEP et d'ailleurs même pourquoi cet adage devrait disparaitre : "pas de mise en prod le vendredi ?"
San un code de qualité on ne peut tout simplement pas développer d'application pérennes, qui vivront et évolueront sur plusieurs années ;, c'est juste impossible. On sera cantonné à faire du site web, des applis de startup, de l'événementiel, du produit de comm' ou encore du POC.
N'y voyez rien de péjoratif, c'est juste un autre job, une autre vie (que j'ai connu).

En fait, parmi les personne qui pratique un code de qualité, qui répondrait que c'est plus cher ? :)

baptiste

Oui
Bon code = bon développeur
Bon développeur = + cher

Un Macbook pro coûte t'il plus cher ?

Moi je répond oui, et non ça dépend... Je vais le garder 10ans.

christian4dev

Non
Comme d'autres l'ont dit, la maintenance et l'évolution d'un produit bien pensé se fait bien plus facilement et coûte donc moins cher. Mais la qualité dès le départ permet de réduire le nombre d'anomalies, que ce soit en qualification ou en recette, voire même avant.
Globalement à court, moyen ou long terme la qualité coûte moins cher.

jm-bertolone

Oui
Bien sur qu'un code de qualité coûte plus cher, mais il respecte davantage le besoin et la demande. On peut donner un hello world mais la qualité n'est pas la.

Si on parle plutôt tdd et des choses dans ce sens, prendre du temps pour tout ce qui phase de réflexion et tdd va coûter moins cher sur le long terme. Après selon moi, sur le court terme cela peut également être valable mais pas pour les tous petits projets. Exemple une api qui sert juste d'interface pour un outil en cli. Tout peut être testé même manuellement et rapidement. Mais dès qu'il grandit il devient nécessaire de faire des vraie phase de tests de bout en bout et là et bien il est nécessaire de mettre en place des tests pour tout ce qui n'a pas été testé auparavant et qui n'est pas forcément très simplement à tester car non développé de façon unitaire.

sebastiencath14

Non
Tout dépend du produit et de l'objectif.
La réponse est OUI, pour un prototype ou un proof of concept. Le quick and dirty sera clairement moins cher qu'un code de qualité, car on ne prend pas en compte la maintenance et l'évolutivité.
Mais dans la plupart des projets informatiques, la réponse est NON.
Quand on veut un produit à maintenir et faire évoluer à moyen et long terme : le code de qualité coute moins cher. L'effort et le temps gagné sur un code déjà de qualité est une MINE D'OR pour les entreprises. Et même si, en effet, l'investissement de départ et plus important, avec le temps et les nouvelles features ça coute moins cher.

jesuisundev

Oui
faire de la qualite prend du temps meme si on a de la methodologie... mais comme deja dit c'est de l'investissement sur l'avenir ( moins de bugs, moins de formation des users dans la cas d'une ergonomie bien pensee et non standardisee par les framework gui) ce n'est bien sur que mon avis basé sur mes 'quelques' annees d'experience dans des secteurs 'un peu speciaux' 😳😉

info

Non
A la base cela peut sembler être le cas, en tout cas pour une direction de projet. En effet, elle pourrait être tenté par ne prendre que des juniors car un bon tech lead a un meilleur salaire, par exemple. Au final, si on compare le coût final, les centaines, voire milliers d’anomalies, les refontes pour palier les problèmes de performance rencontrés, etc. in fine, ça coûte énormément moins cher d’avoir choisi la qualité à la base.

christophe-breheret-girardin

Oui
Même si on écarte les considérations de coûts des changements, vélocité, fiabilité… très bien soulignés dans les autres commentaires, le mauvais code a un coût caché qui est énorme.

C'est un coût humain :
- fatigue cognitive à gérer des conditions à rallonge, des classes vides de sens, du code cryptique…
- frustration à chercher des bugs classe par classe, ligne par ligne, à coup de debugger…
- perte d'implication, à se dire qu'on y peut rien, que peu importe nos efforts, l'état du projet et le consensus au sein de l'entreprise, font que c'est peine perdue…
- pas de montée en compétences des équipes sous pression qui n'ont pas le «temps» de remettre en question leurs pratiques, proposer des améliorations.

Au final, c'est :
- du turn-over dans les équipes : les devs fatigués, frustrés, démotivés, s'en vont
- un répulsif à «talents» (disons simplement «dev impliqué») : un développeur motivé, qui s'implique dans son travail, fait de la veille, veut s'ameliorer, qui «a la flamme», ne voudra pas travailler sur un banal CRUD en code spaghettis, peu ou pas testé, sans CI/CD…

vdebes

Non
La qualité du code se ressent au niveau de l'expérience utilisateur car la réactivité et le bon fonctionnement d'une application éviteront les avis négatif et amélioreront les ventes.

Elle agit aussi dans la capacité d'une entreprise à garder la tête de l'eau sur le long terme puisque si le code est bâclé au début de ira vite, très vite mais le sac de noeud augmentera les estimations qui sont en terme de complexité je le rappelle.

Il est donc évident qu'il faut diminuer la complexité pour livrer aussi rapidement dans 4 ans. Sinon un autre concurent vous bouffera.

Attention cependant à ne pas tomber dans la sur qualité. Si vous devez faire iterer votre connaissance du votre besoin en créant un mvp.

Je pense que pendant les 6 premier mois de la boîte il vaut mieux laisser la qualité de côte car vous beaucoup plus vite à un moment crucial puis sortir une refonte. Il y a de forte chance que votre connaissance du besoin de votre clientèle sera meilleur et que vous pourrez ainsi démarrer votre vrai produit.

Donc je vais répondre pour le contexte d'un produit dont l'objectif est de devenir le leader du marché dans 10 ans

Oui c'est cher mais bien moins cher dans ce contexte que de laisser l'absance de qualité pénalisé l'ambition de votre entreprise

jpasqualini75

Oui
Oui.

Indéniablement oui.

Si on considère le coût de la ligne de code, oui, c'est plus cher. Car déjà, un code de qualité possède moins de ligne. Il est écrit par un développeur mieux rémunérer, dont les années d'expertise, de recherche, de veille et de pratiques sont valorisées.

Donc clairement, le kilo-octet de code de qualité est nettement plus cher que celui pondu à l'arrache.

Après, en ce qui concerne le coût du projet, de la maintenance, des évolutions futures, il est tout aussi évident qu'ils seront bien moins élevés si le code est de qualité. Mais... était-ce la question ?

jordan-mariani

Non
Ca dépend de ce que tu recherches et sur quels critères tu te bases pour estimer qu'un code est de qualité.

Si tu veux écrire un blog rapide pour une opération commerciale limitée, tu seras surtout intéressé par la vitesse de développement. Si tu veux une app bancaire sur le long terme, tu vas favoriser l'absence de bug. Si tu veux une app haute fréquence, tu mettras le curseur sur la performance. Si tu vends des produits de mode, tu feras surtout attention au design. etc. Et tes critères de qualités vont dépendre de tes attentes spécifiques. Dans certains cas, le moins cher sera le mieux. Dans d'autres cas, le concept de coût n'aura aucune importance.

La qualité, c'est le niveau de respect d'une norme.

thierryler

Oui
Si l’objectif est de faire un produit final de très haute qualité cela coûtera toujours plus qu’un produit d’une mauvaise qualité du aux différentes contrôles du produit (Unit Test, Documentation…)

En revanche pour ce même objectif faire un code de qualité dès le début fait gagner du temps ( de facto de l’argent) contrairement à finir le produit par tout les moyen et le rendre stable à la fin

fmarcus28

Non
Si on ne regarde que sur le court terme, oui le code de qualité coûte plus cher.

Mais sur le long terme, un code de qualité c'est potentiellement moins de bug, un dette technique moindre et une maintenabilité accrue. Et comme un code n'est pas remplacé toutes les semaine, l'investissement est moindre sur la durée.

yannick-recht

Oui
Les applications sont devenues jetable, la durée de vie est de 5 ans... Il faut regarder le cout à l'investissement et le comparer avec une durée de vie.
La Lada, c'est certainement parfait pour durée 5 ans.

bruno-regnier

Non
Plus cher que quoi ? Que pas de code du tout ? C'est évident. Alors je reformule la question : pour un produit au même périmètre fonctionnel et aux mêmes capacités fonctionnelles, un code de bonne facture coûte-t-il plus cher qu'un code de mauvaise qualité ?

Commençons par ce que coûte un code de bonne qualité.
- Le recrutement et les compétences de développeurs aguerris et talentueux, qui vont le concevoir. Ces profils ont des raisons d'être plus exigeants quant à leur rémunération et à leur condition de travail. Ils sont plus difficiles à convaincre et à attirer. Mais d'un développeur à un autre, si l'on sait que la productivité peut varier de 1 à 10, le coût salarial ne varie jamais dans des proportions comparables. Autrement dit, il est plus rentable de payer un seul développeur doué et efficace que 2 ou 3 développeurs malhabiles.
- Une revue de code collective, ou ne serait-ce que par un binôme, coûte plus cher que de livrer immédiatement. Et pourtant, cela permet de rattraper des erreurs de conception ou d'identifier des défauts avant qu'ils ne nuisent durablement, et avant qu'ils ne génèrent des pertes financières. Mais surtout, c'est un excellent moyen de niveler les standards de développement d'une équipe vers le haut, pour toujours plus de maîtrise. C'est encore plus vrai avec la programmation binomiale.
- Un code de qualité est un code qui est plusieurs fois remanié, au cours d'un même changement comme lors de changements ultérieurs, afin que la conception soit toujours alignée avec le besoin connu avec simplicité. Mais un code qui n'est pas malléable rend très difficile l'adaptation au changement et incertain son aboutissement, c'est-à-dire la livraison des changements aux utilisateurs. Et plus un logiciel doit changer fréquemment, plus ce manque de malléabilité est un frein aux livraisons. Le contre-coût de la rigidité du code est une explosion du coût du changement pour parvenir à livrer ce qui est attendu de l'extérieur.
- L'automatisation des tests de concert avec les développements oblige à concevoir un code de meilleure qualité : cohésion forte et couplage lâche, pour que le code soit testable. Et l'automatisation des tests représente un coût non-négligeable. Mais les tests ainsi automatisés n'ont ensuite qu'un coût matériel dérisoire d'exécution en comparaison à des campagnes de tests manuels, ce qui permet de les exécuter beaucoup plus souvent, plusieurs fois par jours. Ce faisant, ils constituent un harnais de non-régression pour détecter des anomalies très tôt après leur introduction, de sorte que beaucoup moins de personnes seront mises à contribution en vue de leur identification et correction. L'automatisation des tests réduit donc fortement les coûts en aval des développements.

Ensuite, que coûte un code de mauvaise qualité ?
- Quand la qualité n'est pas intrinsèque au code, il faut créer des dispositifs compensatoires dispendieux à l'échelle de l'organisation afin d'apporter un contrôle extrinsèque de la qualité. Exemple : une équipe de recette usine qui réalise des campagnes répétitives de tests manuels.
- Plus de gestionnaires et de coordonnateurs. Comme les développeurs ne sont pas ou peu responsabilisés par rapport à la qualité de leurs livrables, cette responsabilité échoit à leurs managers, afin que ces derniers décident et arbitrent en périphérie du code source, en terme de périmètre, de délais et de budget. Exemple : 3 à 5 managers pour un seul développeur (oui, c'est possible).
- En conséquence du point précédent, la séparation du budget et de la qualité fait que les optimisations budgétaires sont cloisonnées et décorrélées de la réalité vécue par les équipes. Exemples : des PC bas de gamme alors que le temps perdu par les développeurs coûte bien plus cher, sachant que pour bien produire, il faut les bons outils. Autre exemple : lancer une refonte quand maintenir le logiciel précédent n'est plus rentable.
- Contrairement à ce qu'on pourrait croire, un développeur passe généralement plus de temps à lire du code qu'à en écrire. Plus la qualité du code est faible, moins de temps il pourra consacrer à le faire évoluer. Exemple : 70% ou 80% du temps à lire du code, le reste à en écrire, c'est tout à fait courant. Un code de mauvaise qualité est une vraie source de gaspillage.
- Le temps qui est consacré à la correction des bogues retarde les mises en production. Plus ce temps perdu cumulé est important, plus il est probable de passer à côté d'opportunités d'affaire en clientèle. Exemple : telle fonctionnalité n'est livrée lors d'une présentation du produit à un prospect qui serait passé à l'acte s'il l'avait vue.
- Plus l'effort de recette usine est conséquent, plus les mises en production sont chères. Un moyen de réduire le coût des mises en production est de les raréfier. Mais plus les sorties de version sont espacées dans le temps, moins une organisation occupe son marché : moins d'occasions de communiquer au sujet des nouveautés, des communications moins audibles car trop denses, réunissant des informations hétérogènes et des objectifs disparates.
- Un code de moindre qualité, c'est toujours plus de bogues en sortie. Et l'on sait que le coût de correction n'est pas constant dans le temps : plus le temps passe entre l'introduction d'un défaut et sa découverte, entre la phase de spécification et celle d'exploitation, plus la correction coûte cher, et ce coût augmente de façon exponentielle, d'un facteur 10 à 100 par rapport au coût d'une correction immédiate.
- Plus le code est endetté, plus le coût du changement est important à complexité égale : deux fonctionnalités de même complexité auront un coût très différent selon le temps qui séparera leur réalisation.
- L'absence de qualité pousse les gens vers la sortie, ce qui veut dire plus de recrutement pour les remplacer, le tout accompagné d'une déperdition des connaissances, voire une perte de maîtrise du logiciel.

Quand on parle du coût de la qualité, c'est généralement parce qu'on ne mesure pas le coût de la non-qualité. Car la qualité, celle qui est essentielle pour atteindre ses objectifs, celle-ci rapporte de l'argent, et surtout elle est le moteur de la rentabilité économique d'un logiciel, quel qu'il soit. Un code de bonne facture est donc avant tout un code économiquement beaucoup plus rentable qu'un code de mauvaise qualité.

xapn

Oui
manifesto.softwarecraftsmanship.org

amine-benkeroum

Non
En incluant le coût de release, de maintenance, évolutivité et la moindre prise de risque pour l'activité métier (et donc revenu financier), la qualité coûte moins cher. Mais pour le voir, il faut regarder plus loin que le prix d'achat

dibus

Oui
ça coûte pas cher si on considére que ça entre dans le process du développement.

on peut même aller plus loi et dire t'as des bénéfices si on prend en compte que les bugs coûte très cher en prod.

walider

Non
Pour le coup, je ne sais pas quoi répondre.
OUI, il coûte plus cher à produire que du code dégueulasse. Si on regarde le coût à la sortie du dev, oui, il coûte plus cher qu'un code sans TU, sans revue, etc.
Mais si l'idée est de regarder sur le plus long terme, et de regarder le coup d'un code englobant sa réalisation et ses retouches. Alors là NON, le code de qualité coûte bien moins cher. Et si on ajoute à cela l'insatisfaction client générée par un code de mauvaise qualité, le coût de la non-qualité est énorme !

nico

Oui
Ce qui est terrible dans les métiers d'experts c'est qu'un excellent expert mettra peut être moins de temps à réaliser un acte technique. Si son tarif horaire n'augmente pas en conséquence de son expertise alors oui.. le code de qualité coûtera moins cher. Un vrai paradoxe.

Le problème est donc de savoir valoriser son savoir faire et arriver à le vendre.

Donc je dirai que oui si on entend par qualité un code qui répond aux attentes du client

guillaume-rouffiac

Non
Toujours ramener la qualité à de la tune !
Ce n'est pas cela la qualité.
La qualité c'est la robustesse et pas seulement dans le codage.
Ce qui rejoins une maxime en qualité qui s'applique plus souvent qu'on le crois : "On se fout des moyens, il n'y a que le résultat qui compte"
(Propos de 1986 tenus par un qualiticien que j'ai très bien connu)

godefroyphilippebruno

Oui
Un code de qualité prend plus de temps et/ou d'expérience à un développeur à produire. Le temps se paye et l'expérience aussi donc ça coûte clairement plus cher.
Quand on est pingre, on obtient un produit en carton, que ce soit dans le digital ou dans le monde réel.

jeremy-mouzin

Non
Si c'est un projet long terme, le code sera travaillé et relu plusieurs fois. Un code de qualité permettra de faire ces deux activités plus rapidement et donc coûtera moins chère.
Mais si le projet est court, le code sera probablement jeté et le temps passé à faire de la qualité n'aura aucun retour sur investissement. Ce code aura coûté plus chère.

Au final, la réponse est : non, le code de qualité ne coûte pas toujours plus chère, de même qu'il ne coûte pas toujours moins chère, cela dépend de la phase de développement du produit : prototype vs production.

laurent-bertholle

Oui
Le code de qualité prends plus de temps car il faut dabord reflechir au probleme dans son ensemble, reflechir a une solution sur papier et enfin se mettre a codr . De nos jours on code et on reflechi apres

duflot-axel

Non
C'est au final beaucoup moins cher de maintenir et de faire évoluer un code de bonne qualité, tant au niveau fonctionnel que technique (changement de version du langage par exemple).

pro-2

Oui
Dans notre monde de vision à court terme.
Pourquoi avoir du code de qualité quand on peut avoir un JavaScript qui marche fait par le stagiaire Java.

guy_omen

Non
Le meilleur code est court et documenté. Cela sous-tend une grande intelligence! C'est le prix de l'intelligence contre la quantité qui nécessite beaucoup de contrôle. La minute coûte cher, le résultat non.

f6cng-68

Non
Considérant que faire les choses salement n'est moins cher qu'à court terme, et que la majorité des coûts d'un logiciel sont dans la durée et pas dans l'effort initial.

jonathan-maurice

Non
Le temps de tests manuels et les régressions que ça m'a évité pendant la conception d'une api ! J'aurai dû prendre le temps de l'apprendre sur le côté utilisateur contre l'avis de mon boss. Ne serai-ce que pour savoir si les pages s'affichent, parcequ'il est pas le seul à transpirer quand ça se passe pas comme prévu XD

ramadanoski-j

Non
Ça coûte forcément plus cher directement (plus de tests par exemple si tu fais du TDD) mais derrière on s'y retrouvé largement ! Donc non ça ne coûte pas plus cher

nowaksim

Non
Ne pas confondre qualité d'un produit et valeur d'un produit sur le marché. Une belle conception coûte moins cher dans le dev logiciel car on retire la complexité accidentelle. Soucis, il faire trouver les talents existant et former les futurs. Dans un monde où la qualité n'est pas un objectif de programme de développement logiciel, ces derniers sont voués à l'échec et l'explosion des coûts d'exploitation et de maintenance. Là où un logiciel bien conçu sera ouvert aux changements et à l'usage exponentiel avec un coût constant en fonction des besoins d'évolution.

bbohec-pro

Non
Pour ceux qui veulent faire un produit a l'arrache / éphémère, le code de qualité coûte plus cher et ne sert a rien de plus qu'un code fait a l'arrache pour pas cher. Par contre, le code rapide coûtera cher en debug.

Quand on fait un projet pérenne et qu'on veut économiser beaucoup sur le debug, (et ajouter en fiabilité) il est très intéressant de mettre le paquet sur la spec initiale, la conception, le code de qualité et les tests. Le projet initial coutera plus cher. La qualité deviens rentable au bout de 1 a 2 ans.

camille-khalaghi

Non
Le coût du développement est principalement lié au temps passé par les équipes pour réaliser une tache. Pour moi un bon développeur ne code pas moins vite en faisant de la qualité, c'est même le contraire en fait. Bien évidement le rework est plus facile mais même l'ajout d'une nouvelle fonctionnalité dans un code de qualité est bien plus rapide. La qualité ça fait gagner du temps dans le monde professionnel à tous les niveaux.

Il ne faut pas confondre qualité et luxe comme dans le cas des voitures ;)

gecedric

Non
Le prix en lui-même n'est pas seule équation de la composante.
La durée de maintenance/évolution du système qui contient se code a un impact notable.
Au démarrage d'un projet, du code de qualité a un impact sur le coût. Celui-ci sera plus élevé qu'un code non qualitatif. Et par code non qualitatif, j'entend mal organisé, posé sur un système sans architecture viable, sans tests automatisés , ... .
En revanche, bien que moins cher au démarrage, un code non qualitatif, se verra plus cher au fur et à mesure du temps, le manque de tests automatisés (ou non d'ailleurs) ne permettra pas de détecter certains bugs avant la livraison, et impliquera donc des aller-retours fréquents avec le client.
La mauvaise sélection architecture impliquera de tordre le code ou l'environnement dans lequel il se trouvera.
Et sur le long-terme, la stabilité inhérente du code qualitatif permettra de livrer des fonctionnalités à un coût relativement stable (là où son opposé se verra affilié des coûts de plus en plus important).
Sur le long-terme donc, le code qualitatif est moins cher.
Mais attention, un code qualitatif peut se transformer en non qualitatif si on ne lui applique la même rigueur tout au long de sa vie.

mimil-aime-le-pastaga-le-51

Non
Oui naïvement, et non finalement.

Effectivement, d'un point de vue "ressources", un code de qualité va en nécessiter davantage. Rédiger la documentation interne (type JavaDoc, Doxygen, Dokka, ...), écrire les tests unitaires ou fonctionnels pour la non-regression, vérifier les métriques... tout ceci demande du temps, des hommes/jours, et donc coûte plus cher.
Sur le court terme, oui.

Toutefois sur le long terme cela va éviter d'avoir des régressions, des défauts, des surcharges liées au fait d'avoir un code de piètre qualité. Le code pourri coutera plus cher et sera source de problèmes.

Donc sur le long terme, non, pas spécialement, et c'est surtout ça qui compte.

pylouq

Non
qu’est ce qu’un code de qualité ? Cela pourrait être l’objet d’une prochaine bataille 😝.

En ce qui me concerne, le client ne se soucis pas de la qualité du code (il y comprend souvent pas grand chose). Il se soucie des heures qu’on lui facture. a partir de ce postulat a nous d’être plus performant que nos concurrents pour délivrer la meilleure prestation au meilleur coût. Et c’est là que la bataille de l’efficience commence entre codeur. Donc il est difficile de parler de prix et de qualité quand on parle de code car ce n’est pas un critère en soi, à mon sens, retenu par le client.

tedmarch

Non
Ni Oui, Ni Non, car qu'est-ce qu'un code de qualité ?
Un code qui est conforme à des règles d'écriture ?
Un code couvert par des tests unitaires, fonctionnel ?
Un code qui est performant ?
Un code qui est générique ?
Un code qui est ré-utilisable ?

S'il faut répondre Oui à tout, le code de "qualité" sera plus cher, par contre, s'il faut répondre OUI en fonction du projet et de sa durée de vie, alors là non et de loin !!!!

sauget-marc

Non
On ne reviens pas dessus, la production est plus longue mais plus pérène. Vu qu'on n'y reviens pas, le code est moins cher dans la période de garantie

nonalweb

Non
Oui sur le court-terme, non sur le long-terme

bernardo

Non
A moyen et long terme, non. Le code de qualité sera plus facile à maintenir/refactoriser si on a bien sur tout ce qu'il faut comme bagage pour munir à bien ça (avoir les bons dev qui pratiquent 100% TDD, comprennent DDD, principes SOLID ... + avoir l'environnement pour faire ça 😀)

trmalek

Non
Au début « peut-être » mais sur le long terme non pas du tout, c’est l’inverse!

anass-derri

Non
Ce n'est pas le code de meilleur qualité qui coûte plus cher, mais le temps de conception/réflexion nécessaire en amont. Cependant, il est amorti par des coups de maintenance réduit.

nozzle-one

Non
Au début du projet, cela va prendre du temps et risque donc de coûter plus cher. Quand le projet aura déjà un certain temps, cela permettra d'éviter des problèmes et donc de faire gagner du temps et de l'argent

bht_kent

Non
Dune part on devrait d'abord se poser la question de savoir qu'est ce qu'un code de qualité.
Est ce qu'il s'agit du code qui va correspondre au mieux à ce que l'utilisateur final à exprimer, sachant que le besoin évolue pour une grande partie en fonction de e qui est produit et donc après le premier jet de code ?
Ou bien s'agit il du code qui sera le plus performant en terme de cout ?
Par ailleurs l'autre question à se poser est de savoir quelle est la place du code dans le cycle de vie d'un produit traité par des méthodologies modernes comme agile.

saxisk