Discussion :

[Christian Olivier]

Les développeurs consacrent trop de temps à corriger le mauvais code
Au lieu de se focaliser sur de nouveaux projets, ce qui pénalise les entreprises

À mesure que la technologie se dilue dans tous les aspects de l’économie mondiale, les ingénieurs informatiques en génie logiciel apparaissent de plus en plus comme l’une de leurs ressources les plus précieuses.

Une étude publiée récemment par Stripe, l’éditeur d’une plateforme et d’applications de paiement en ligne, semble valider l’hypothèse selon laquelle l’allocation d’une trop grande quantité de temps à la maintenance plutôt qu’au développement de nouveaux projets peut avoir un impact économique non négligeable sur une organisation.

L’enquête a été menée pour Stripe par l’institut Harris Poll. Plus de 2000 développeurs, responsables techniques et des cadres supérieurs de niveau C à travers six pays (incluant la France, l’Allemagne, le Royaume-Uni, Singapour et les États-Unis) ont été interrogés. Elle présente les développeurs comme un facteur qui reste encore trop négligé, alors qu’il peut avoir un impact décisif pour le succès futur d’une entreprise (production, vente, différentiation, visibilité, etc.). Cette étude fournit également un aperçu de la vision des décideurs dans le milieu entrepreneurial.

Une très grande partie des cadres supérieurs sondés estiment que leurs entreprises aujourd’hui sont confrontées à des défis qui vont bien au-delà de leur simple objectif de rentabilité. Ces challenges sont essentiellement d’ordre sécuritaire (66 %) et règlementaire (62 %), concurrentiel (60 %) ou liés à la disponibilité d’une main-d’œuvre de qualité (61 %). ils sont plus préoccupés par les questions ayant trait à l’accès à l’information et à la technologie que des problèmes liés à l’immigration et à l’accès au capital ou aux marchés.

La majeure partie des cadres supérieurs (44 %) estiment que leurs concurrents de l’industrie de la technologie représentent la plus grande menace pour leurs activités. C’est pour cette raison qu’ils envisagent de prioriser les investissements sur l’infrastructure logicielle (41 %), la R&D (31 %) et le recrutement (31 %) au cours des cinq prochaines années.

Les développeurs et les exécutifs de niveau C s’accordent à dire que l’intelligence artificielle (IA), les services basés sur les API et l’Internet des Objets (IoT) représentent les tendances technologiques qui actuellement impactent le plus fortement sur leurs activités. Le Machine Learning (ML), les assistants virtuels et la Blockchain devraient compléter cette liste dans les dix prochaines années.

Les cadres supérieurs sont un peu plus optimistes que les développeurs lorsqu’on leur demande s’ils pensent que leurs entreprises disposeront de ressources suffisantes pour tirer parti de ces tendances technologiques (83 % contre 77 %). Les développeurs qui ne partagent pas ce point de vue optimiste justifient leurs inquiétudes par le fait que leurs entreprises sont trop lentes à régir, ne disposent pas de suffisamment d’employés qualifiés ou des infrastructures techniques adéquates, mais aussi par le fait que les dirigeants de leurs entreprises n’accordent pas suffisamment de priorité à la technologie.

Bien qu’il soit prioritaire pour les cadres supérieurs d’accroitre la productivité de leurs développeurs (96 % l’ont signalé), cette étude montre que chaque développeur consacrerait en moyenne plus de 17 heures par semaine (jusqu’à 20,9 heures en France) à la maintenance : débogage, refactoring, etc. Chaque développeur passerait près de 4 heures à retoucher du « mauvais code », plutôt que de s’investir dans de nouveaux projets.

Six développeurs sur dix jugent eux-mêmes « excessif » le temps dédié au « mauvais code ». Pour les entreprises qui les emploient, ce qui à l’échelle mondiale équivaudrait chaque année à un manque à gagner d’environ 85 milliards USD en termes de « cout d'opportunité ».

Les développeurs (18 millions dans le monde) peuvent agir ensemble comme un « multiplicateur de force » puisque, comme l’a précisé l’enquête, ils « ont le potentiel, collectivement, d’augmenter le PIB mondial de 3000 milliards de dollars au cours des dix prochaines années ». Les organisations qui les emploient auraient donc tout intérêt à les « utiliser » plus efficacement.

Source : Stripe (PDF)

Et vous ?

Que pensez-vous des données exposées dans cette étude ?

Voir aussi

Emploi développeur 2017 : les langages les plus demandés et les mieux payés, Java, JavaScript et PHP plus demandés, mais Perl, Go et Scala mieux payés
France : en 2017, 32 % des logiciels installés en entreprise ne disposaient pas d'une licence conforme, d'après une étude de la BSA
Avez-vous déjà travaillé avec un développeur qui se sert de méthodes frauduleuses ? Partagez votre expérience
Trolldi : à partir de quel âge est-il raisonnable pour un développeur de s'orienter ailleurs ?

[sebastiano]

Les décideurs dans les entreprises n'ont pas toujours conscience qu'une bonne équipe d'ingénieurs va conduire au succès. De plus, beaucoup de ces sociétés sont parasitées par des éléments qui ne produisent rien. Ou trop peu par rapport au salaire engrangé (et je ne parle pas que des autres métiers, j'ai connu des dévs web à 70k brut incapables de créer une vue).

[CaptainDangeax]

Ma mission actuelle arrive à son terme, le projet est bouclé et fonctionnel. Je n'ai pas eu à toucher au code powershell de mon prédécesseur, à part pour rajouter un cas de configuration non prévu au départ. Par contre, j'ai ré-écrit 80% de ce qu'il avait écrit en bash...

Les décideurs dans les entreprises n'ont pas toujours conscience qu'une bonne équipe d'ingénieurs va conduire au succès. De plus, beaucoup de ces sociétés sont parasitées par des éléments qui ne produisent rien. Ou trop peu par rapport au salaire engrangé (et je ne parle pas que des autres métiers, j'ai connu des dévs web à 70k brut incapables de créer une vue).

De mon coté, j'ai connu des ingé système qui étaient des quiches en BDD, donc complètement paumés dès que les données sont stockées dans un SQLITE ou autre ; inutile de leur demander un rapport.
Il y a aussi les chefs de projet slideware (spécialistes powerpoint, pauvre point en français), qui ne savent pas identifier un chemin critique et pour qui une socket réseau c'est du babylonien.
Enfin, il y a les pipeauteurs de CV, qui se font repérer rapidement, comme un ingénieur système windows qui ne savait pas importer un fichier texte dans excel.

[Edrixal]

Que c'est plutôt représentatif du monde dans lequel nous vivons. Les gens pense avoir la science infuse, les gens n'arrive pas à comprendre qu'une personne ne puisse pas avoir les mêmes connaissance qu'eux, les gens n'arrive pas à accepté que l'on puisse penser et faire différemment d'eux (sans pour autant être dans le faux), ect...

Il suffit de voir les réactions apporter ici pour comprendre que les dev semble plus s'attarder sur des détails comme "Les commentaires sont écrit en Français !" ou "Franchement j'aurais pas fait comme ça, là c'est n'imp" plutôt que d'essayer de comprendre la logique du code, le pourquoi il à été développer ainsi, de comprendre que les personnes qui on développer dessus n'avais probablement pas le temps de reprendre le projet, que le projet est vieux et qu'il est passer entre plusieurs main, ect...

En fait je pense qu'a force de vouloir prouver que l'on est toujours meilleurs que son voisin quitte à lui écraser la gueule pour rien, c'est le mot d'ordre. Ainsi plutôt que d'aider son collègue à développer ses compétences on lui écrase la tête dans son caca en lui disant "t'es nul !".

[Tagashy]

en lisant cet article je me demande mais qu'est ce qu'il se passe dans la tête de ces gens Oo.

Je suis totalement d'accord sur le fait que c'est chiant de debugger un code pourris mais par contre c'est vital ...
Petit exemple : qu'est ce qui est le plus important entre faire fonctionner un moyen de payement qui bug suite à la mise à jour XXX du fournisseur, ou implémenter un chariot intelligent qui prédirais les achats.
Pour un dev, le deuxième point est plus intéressant que le premier mais il faut penser logique métier et dans ce cas on se rend compte que niveau criticité le premier est largement plus important ...
Je développe un soft de génération de rapport, et oui je préfère ajouter un nouveau graphe que de corriger l’alignement des colonne du tableaux X ou cherchez pourquoi les données XY qui devrais être ici n'y sont que partiellement , mais un des deux affecte le clients immédiatement et l'autre l'affecte dans le futur...

Je sais pas si je suis clair mais pour moi la maintenance est chiante mais nécessaire contrairement à ce que me laisse pensé cet article

[sebastiano]

Il suffit de voir les réactions apporter ici pour comprendre que les dev semble plus s'attarder sur des détails comme "Les commentaires sont écrit en Français !" ou "Franchement j'aurais pas fait comme ça, là c'est n'imp" plutôt que d'essayer de comprendre la logique du code, le pourquoi il à été développer ainsi, de comprendre que les personnes qui on développer dessus n'avais probablement pas le temps de reprendre le projet, que le projet est vieux et qu'il est passer entre plusieurs main, ect...

C'est loin d'être l'apanage des devs.

Des réunions retardées, reportées ou dénoncées pour 1 faute d'orthographe dans un doc technique, ou un client qui refuse une présentation faite par un interlocuteur maîtrisant le Français mais ayant un très léger accent, ou encore des prises de tête violentes parce que la patron du pôle dev a osé mettre un cheveux dans le périmètre du pôle intégration pour faire avancer le projet.

Au-delà des détails, c'est plutôt un trait très français dans les entreprises, que de pointer des responsabilités ou des détails plutôt que d'agir pour le bon déroulé du projet. Et ce, à tous les niveaux.

[el_slapper]

(.../...) (et je ne parle pas que des autres métiers, j'ai connu des dévs web à 70k brut incapables de créer une vue).

Vu aussi. Enfin, pas en web, c'est pas mon domaine, mais vu.

Le souci à mon sens vient de plus loin. On a des besoins énormes en terme de production de code. Jusque là, je pense ne surprendre personne. Donc on forme plus de gens. Mais il y a une incompréhension fondamentale du marché sur ce qu'est un programmeur(c'est sans doute vrai aussi dans d'autres domaines, mais pour le coup, j'assume ma propre incompréhension des autres domaines). Dans l'esprit des non-programmeurs, c'est juste un technicien, qui apprend une technique, et qui l'applique. D'ou le matching massif des recruteurs/commerciaux sur les mots-clefs, d'ailleurs.

En fait, non. Un programmeur, c'est (1)quelqu'un qui est capable de concevoir une méthode aussi élégante, courte, et efficace que possible pour permettre à la machine de prendre une série de décisions pertinentes, telles qu'attendues par les utilisateurs. C'est donc quelqu'un qui a besoin d'une certaine culture intellectuelle(d'ou les forums comme DVP ou on débat de la pertinence des getters/setters par rapport aux propriétés/méthodes, et de ce que ces termes doivent recouvrir). C'est (2)quelqu'un qui a besoin d'être capable de réfléchir à plusieurs niveau d'abstraction simultanément(une qualité qui me semble innée. Je peux avoir tort, mais je n'ai jamais vu quelqu'un l'acquérir). C'est (3)quelqu'un capable de soumettre son esprit à l'idée que la machine n'infère rien, que la machine n'est pas un humain, et que si la machine répond mal, c'est de la faute à la question. Toujours.

Mais au lieu de filtrer sur le point 2, et de donner une éducation complète sur les points 1 et 3, on se focalise sur des détails techniques. Et on fait apprendre aux gens les design patterns par cœur, au lieu de leur faire découvrir pourquoi(et dans quelles circonstances) ils sont pertinents. Et on filtre sur les maths, qui ne sont pas un filtre optimal, restons polis. Ce qui nous fait parfois des gens qui n'ont pas la bonne tournure d'esprit, et souvent pas la formation intellectuelle pour rentrer dans le dur. Et en plus, on forme en masse. Dans un domaine ou la qualité est primordiale, on privilégie la quantité. Et mal ciblée, en plus. A laquelle on rajoute le jeunisme qui nous prive de ressources sénior qui feraient tellement de bien.

Et on se retrouve avec ton dev web, qui a un niveau de maths honnête, qui connait plus ou moins ses outils techniques, mais est incapable de faire une vue(je ne sais pas ce que c'est, je ne connais rien au web), c'est probablement quelqu'un qui est bloqué sur des points que j'ai cité. Peut-être même les trois. Et il laisse derrière lui tout ce mauvais code qui nécessite tant de temps à nettoyer(pour retourner au sujet initial).

[Pyramidev]

Il suffit de voir les réactions apporter ici pour comprendre que les dev semble plus s'attarder sur des détails comme "Les commentaires sont écrit en Français !" ou "Franchement j'aurais pas fait comme ça, là c'est n'imp" plutôt que d'essayer de comprendre la logique du code, le pourquoi il à été développer ainsi, de comprendre que les personnes qui on développer dessus n'avais probablement pas le temps de reprendre le projet, que le projet est vieux et qu'il est passer entre plusieurs main, ect...

En fait je pense qu'a force de vouloir prouver que l'on est toujours meilleurs que son voisin quitte à lui écraser la gueule pour rien, c'est le mot d'ordre. Ainsi plutôt que d'aider son collègue à développer ses compétences on lui écrase la tête dans son caca en lui disant "t'es nul !".

Pour la partie « Franchement j'aurais pas fait comme ça, là c'est n'imp », je fais probablement partie des gens visés, car j'ai critiqué le nommage des variables ici et certains amas de valeurs en dur dans le code là. Donc j'ai critiqué le code, mais à aucun moment dans le fil je n'ai affirmé que les développeurs qui avaient écrit ce code étaient nuls. Je sais que, s'il n'y a pas eu assez de temps consacré au réusinage de code, ce n'est pas forcément la faute des développeurs.

Dans mon premier message, j'avais réagi à ta phrase « Dans l'ensemble d'un avis personnel, je trouve le code clair et lisible. »

[xarkam]

d’ordre sécuritaire (66 %) et règlementaire (62 %)

On a peur du vol d'informations, d'intrusion dans l'infra, du social engineering. (l'ordre sécuritaire)
On veux cadrer plus fortement les employés par des règlements plus strict et précis. (En expliquant que c'est bon pour la sécurité)

concurrentiel (60 %) ou liés à la disponibilité d’une main-d’œuvre de qualité (61 %).

Le nerf de la guerre tout en voulant une main-d’œuvre de qualité payée au lance pierre pour être concurrentiel.

Bien qu’il soit prioritaire pour les cadres supérieurs d’accroitre la productivité de leurs développeurs (96 % l’ont signalé)

96% des cadres sup ne comprennent rien au travaille de développeur et les considères un peu comme des féniasses non productives.

Six développeurs sur dix jugent eux-mêmes « excessif » le temps dédié au « mauvais code »

Tout n'est que notion appréhension. Si un code est mauvais, soit il ne fait pas ce pour quoi il a été fait, soit il est pas fonctionnelle.

Qui en tant que développeur n'a pas connu un projet donc les besoins évoluent en cours de route?
Un code ne peux pas être mauvais si le besoin auquel il devait répondre a évolué.

Tant que le code fait ce pour quoi il a été codé, il n'est en rien mauvais.

Après, il est bien connu que les dev ont un égo tellement surdimensionné que cela joue aussi dans la balance.

[disedorgue]

Si au départ, il n'y avait pas de mauvais code, il n'y aurait pas besoin de le corriger

[el_slapper]

Si au départ, il n'y avait pas de mauvais code, il n'y aurait pas besoin de le corriger

Le code peut être juste à un instant T, et faux à l'instant T+1. Genre un code qui ne travaille qu'en francs. Parfaitement juste jusqu'au premier janvier 2002, et soudain terriblement obsolète.

[Paul TOTH]

j'aimerai comprendre...

[...]des défis qui vont bien au-delà de leur simple objectif de rentabilité[...]Bien qu’il soit prioritaire pour les cadres supérieurs d’accroitre la productivité de leurs développeurs[...]ce qui à l’échelle mondiale équivaudrait chaque année à un manque à gagner d’environ 85 milliards USD [...]Les développeurs [...] « ont le potentiel, collectivement, d’augmenter le PIB mondial de 3000 milliards de dollars au cours des dix prochaines années ». Les organisations qui les emploient auraient donc tout intérêt à les « utiliser » plus efficacement.

en ne parle pas de rentabilité c'est bien ça ?

Senior executives report that the lack of developer talent is one of the biggest
potential threats to their businesses. In fact, they now worry about access to
developers more than they worry about access to capital, immigration concerns, and
other challenges. Despite the number of developers increasing year-over-year at most
companies, developers working on the right things can accelerate a company’s move
into new markets or product areas and help companies diferentiate themselves at
disproportionate rates. This underscores the most important point about developers
as force-multipliers: It’s not just how many devs companies have; it’s also how they’re
being leveraged.

cette étude voudrait démontrer que ce n'est pas le manque de développeurs qui est le problème aujourd'hui mais le fait que les développeurs ne travailleraient pas sur les bons sujets...la maintenance coûte cher et ne rapporterait rien, pas besoin de plus de fonctionnaires développeurs, il suffit de faire bosser correctement ceux qu'on a...et bientôt on nous dira qu'il y a trop de fonctionnaires développeurs, l'IA, les blockchain (et les rouleaux à pâtisseries) permettant d'être bien plus efficace que par le passé, il suffit de réorienter leur force de frappe sur de vrais sujets.

[hacksow]

Edrixal, je suis d'accord avec toi on est toujours dans la critique à l'époque les développeurs s'entraidé, il n'y avait pas de moi je suis le meilleure. Il y a des personnes qui ont vraiment un problème avec leur égo et ils s'étonnent que personne les apprécie....

[disedorgue]

Le code peut être juste à un instant T, et faux à l'instant T+1. Genre un code qui ne travaille qu'en francs. Parfaitement juste jusqu'au premier janvier 2002, et soudain terriblement obsolète.

Oui, mais là, on est sur une évolution, pas sur de la correction...

Et ton exemple peux aussi être vu comme du mauvais code, si celui-ci a été fait par exemple en juin 2001, alors que l'on savait déjà que le franc allait disparaitre.

Donc, la question déjà à se poser est de déterminer ce que l'on appelle du mauvais code ?

[mister3957]

Là je sors d'une expérience pitoyable où les décideurs techniques ont décidé :

- Une API REST c'est juste du CRUD
- La base de données en NodeJS c'est Mongo (et puis SQL on connait pas donc on zappe)
- Côté front, il faut que ça soit simple, donc on va faire un seul formulaire qui fait tout dans tous les contextes
- Pourquoi s'emmerder avec un système d'authentification ? Si on est sur cette page c'est que c'est tel type d'acteur et pour identifier le client on a qu'à faire des sous domaines.
- On va faire du SCRUM parce que c'est la mode, bien évidemment inutile de se former sur les différents rôles
- Et puis il n'y a plus qu'à presser les "codeurs" à coups de "vite vite vite, on a déjà vendu le truc"

Avec des mentalités pareilles d'apprenti sorcier, c'est même pas la peine de démarrer.

[sebastiano]

Oui, mais là, on est sur une évolution, pas sur de la correction...

Et ton exemple peux aussi être vu comme du mauvais code, si celui-ci a été fait par exemple en juin 2001, alors que l'on savait déjà que le franc allait disparaitre.

Donc, la question déjà à se poser est de déterminer ce que l'on appelle du mauvais code ?

Non, ce n'est absolument pas du mauvais code. C'est de l'ordre de la définition du besoin.

[Edrixal]

je fais probablement partie des gens visés,

Je rebondi juste sur cette phrase pour dire que je ne cité personne personnellement et que je n'ai pris cette discutions en exemple que parce qu'il était plus simple d'expliquer mon point de vue ainsi que de faire une longue logorrhée sur les prises de tête que j'ai pu avoir avec certaine personne dans la vie qui par exemple, me prenais la tête parce que mes dev (nom de variable/fonction, commentaire, message d'erreur, ect...) sont en Français et non en Anglais.

Donc, la question déjà à se poser est de déterminer ce que l'on appelle du mauvais code ?

D'un avis personnel toujours, un mauvais code est un code qui ne fait pas ce qu'il devrait faire (bug, oublie de certain module ect...). Sinon, même si le code est fait n'importe comment, mais que le résultat est là, le code fonctionne, il n'est donc pas mauvais.

Je mettrait tout de même un bémol sur les personnes qui écrivent volontairement leur code n'importe comment pour être les seuls à pouvoirs les maintenir et les faire évoluer correctement et facilement. Quoi qu'a ce niveau là ce serait plutôt le dev qui serait mauvais que son code finalement

[Tagashy]

- Une API REST c'est juste du CRUD
- La base de données en NodeJS c'est Mongo (et puis SQL on connait pas donc on zappe)
- Côté front, il faut que ça soit simple, donc on va faire un seul formulaire qui fait tout dans tous les contextes

en fonction des besoin cette partie peux se comprendre, non? je veux bien que tu m'explique les problèmes .

- Pourquoi s'emmerder avec un système d'authentification ? Si on est sur cette page c'est que c'est tel type d'acteur et pour identifier le client on a qu'à faire des sous domaines.
- On va faire du SCRUM parce que c'est la mode, bien évidemment inutile de se former sur les différents rôles
- Et puis il n'y a plus qu'à presser les "codeurs" à coups de "vite vite vite, on a déjà vendu le truc"

La je te soutient par contre, c'est nawak ^^

[disedorgue]

Non, ce n'est absolument pas du mauvais code. C'est de l'ordre de la définition du besoin.

Donc, on en revient que là, on ne corrige pas, on fait évoluer en modifiant le code voir le remplacer totalement à cause de la nouvelle définition du besoin.

Qu'appelle-t-on un mauvais code:

• Un code obsolète vis à vis des évolutions de besoin ?
• Un code fait avec les pieds (mais qui réponds au besoin) ?
• Autre ?

Selon la définition que l'on se fera de "mauvais code", l'étude aura une tout autre connotation...

Enfin, c'est mon avis.

[sirthie]

C'est loin d'être l'apanage des devs.

Des réunions retardées, reportées ou dénoncées pour 1 faute d'orthographe dans un doc technique, ou un client qui refuse une présentation faite par un interlocuteur maîtrisant le Français mais ayant un très léger accent, ou encore des prises de tête violentes parce que la patron du pôle dev a osé mettre un cheveux dans le périmètre du pôle intégration pour faire avancer le projet.

Au-delà des détails, c'est plutôt un trait très français dans les entreprises, que de pointer des responsabilités ou des détails plutôt que d'agir pour le bon déroulé du projet. Et ce, à tous les niveaux.

Parce que tu compares du mauvais code à "1 faute d'orthographe dans un doc technique" ? Quand j'ai du refaire des pages web, j'ai dû les refaire from scratch tellement le code était pléthorique, obsolète, redondant, etc., etc.

Optimiser le code FAIT PARTIE (ou devrait faire partie) du "bon déroulé du projet. Et ce, à tous les niveaux". Pas pour faire chier les gens, mais parce que sur la durée, c'est une nécessité. En tout cas dans le web.