IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Des développeurs démissionnent pour échapper aux mauvaises pratiques de codage de leurs entreprises, d'après un récent sondage
Qui pointe la dette technique comme raison de ce choix d'un lot de 51 %

Le , par Patrick Ruiz

119PARTAGES

10  0 
Le sondage est de Stepsize – une société qui se concentre sur la gestion de la dette technique en suivant les problèmes de développement autour de solutions telles que l’éditeur Visual Studio Code. 51 % de l’échantillon des deux cent développeurs participant à l’enquête pointent les mauvaises pratiques de codage de leurs entreprises comme possible raison d’une démission de leur part. Vous est-il arrivé de présenter une démission pour des raisons en lien avec la gestion de la dette technique ? Ces chiffres sont-ils en accord avec la réalité dont vous êtes au fait ?

« Plus de la moitié des personnes interrogées affirment que leur entreprise ne gère pas bien la dette technique, ce qui montre que le fossé entre les ingénieurs et les dirigeants se creuse au lieu de se combler. Les ingénieurs sont clairement convaincus que la dette technique est la principale raison des pertes de productivité, mais ils semblent avoir du mal à en faire une priorité », indique l’étude.


Les développeurs comme dans les autres corps de métier sont généralement désireux de partir vers d'autres entreprises pour gagner plus d'argent, relever de nouveaux défis ou bénéficier d'options de travail plus souples. L’enquête de Stepsize vient de mettre en évidence une raison additionnelle pour laquelle les ingénieurs en informatique pourraient vouloir démissionner : la mauvaise qualité du code de leurs collègues. Les sollicitations dans le métier d’ingénieur en développement de logiciels sont fréquentes en matière de gestion de la dette technique créée par des pratiques de codage passées non documentées et exotiques.

La gestion de la dette technique est cependant plus large. Le terme peut tout couvrir, depuis une implémentation informatique majeure, comme un système bancaire central qui nécessite une décennie de corrections de bugs, jusqu'au choix du langage de programmation pour construire les systèmes dorsaux. Dans ce dernier cas, les mises à jour ultérieures du langage peuvent obliger les développeurs d'aujourd'hui à réécrire un ancien code écrit par des développeurs de longue date qui écrivaient dans des conditions différentes et qui n'ont peut-être pas documenté ce qu'ils faisaient et pourquoi ils le faisaient. C'est un gros problème pour les entreprises qui ont des millions de lignes de code écrites dans un langage.

La charge de travail y relative est source de baisse de morale chez les développeurs comme le souligne Stepsize : « Le moral des employés est l'une des choses les plus difficiles à gérer, surtout maintenant que les entreprises adoptent des solutions de travail à distance à long terme. L'enquête révèle que la dette technique est en fait un facteur important de la baisse du moral. Les développeurs ont souvent l'impression d'être obligés de donner la priorité aux nouvelles fonctionnalités au détriment de travaux de maintenance essentiels qui pourraient améliorer leur expérience et leur vitesse de travail, ce qui a un impact considérable. »


En sus, l’enquête souligne que 20 % de l’échantillon interrogé pointe le type de dette technique comme l’une des raisons principales du départ d’une entreprise pour laquelle ils ont travaillé. Grosso modo, la gestion de la dette technique apparaît au 4e rang des raisons mises en avant par les participants au sondage de Stepsize. La question salariale arrive néanmoins en tête avec une concentration de 82 % des participants.

Des développeurs peuvent de plus chercher à changer d’employeurs en raison du manque de défis techniques et de possibilités de croissance. 75 % de l’échantillon interrogé partage cet avis. De plus, dans un contexte mondial marqué par la pandémie de coronavirus, 68 % ont pointé la possibilité de travailler à distance comme un facteur déterminant pour poursuivre avec une entreprise donnée.

Source : Stepsize

Et vous ?

Quels sont les canons en matière de gestion de la dette technique dans l’entreprise pour laquelle vous travaillez ? Quels sont les aspects qui sont à revoir selon vous ?
Vous est-il arrivé de déposer une démission en raison de la mauvaise qualité de code de vos pairs ? Partagez votre expérience

Voir aussi :

Hype Driven Development : quelles sont les technologies adoptées par les équipes de développement en suivant tout simplement la mode ?

La difficulté à recruter de bons ingénieurs en informatique résulte-t-elle de la baisse générale du niveau scolaire, notamment en maths et en sciences ?

Un ingénieur en informatique de Netflix gagne plus de 300 000$ par année. Pourquoi cette entreprise paie-t-elle plus que Google et Facebook ?

Ingénieur Full Stack : mythe ou réalité aujourd'hui ? Peut-on vraiment avoir un haut niveau d'expertise du back-end au front-end ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de eric44000
Membre régulier https://www.developpez.com
Le 02/10/2021 à 0:58
Citation Envoyé par Patrick Ruiz Voir le message
« Plus de la moitié des personnes interrogées affirment que leur entreprise ne gère pas bien la dette technique, ce qui montre que le fossé entre les ingénieurs et les dirigeants se creuse au lieu de se combler. Les ingénieurs sont clairement convaincus que la dette technique est la principale raison des pertes de productivité, mais ils semblent avoir du mal à en faire une priorité », indique l’étude.
Une entreprise qui ne gère pas la dette technique est vouée à la faillite. Autant on peut concevoir qu'un code ne soit pas optimal quant à l'évolutivité par manque de temps (date de livraison), autant elle doit consacrer du temps à réécrire certaines parties pour rendre la maintenance moins lourde à l'avenir.
9  0 
Avatar de Obsidian
Modérateur https://www.developpez.com
Le 02/10/2021 à 1:21
… ou alors, il faut accepter de faire du code jetable.

Ça peut être une approche, à condition de bien jeter le code à la date convenue ! Il arrive encore trop souvent que l'on se dise « bon, ben finalement, ça fait x années que ce bricolage rend service, donc on considère que c'est acquis. ».
8  0 
Avatar de epsilon68
Membre éprouvé https://www.developpez.com
Le 02/10/2021 à 10:19
Ce n'est pas seulement la dette technique qui fait partir, mais aussi la non-volonté de la résorber (pas le temps, urgences, ce n'est pas le moment etc), ainsi que de penser documentation = non-productivité.

Le management ne comprend pas que faire un logiciel c'est assez "facile" (on prend les nouvelles technos etc), le maintenir c'est la difficulté, il faut avoir une archi robuste qui supporte les changements, il faut plusieurs personnes pour ne pas avoir du code que personne ne connait si le dev part, il faut de la doc pour garder la connaissance et expliquer les contraintes.

Le court terme c'est simplement tout ce qui compte on dirait...
4  0 
Avatar de sergio_is_back
Expert confirmé https://www.developpez.com
Le 02/10/2021 à 11:11
Citation Envoyé par smarties Voir le message
L'entreprise dans laquelle je suis utilise des technologies dépassées à mon goût : Delphi
C'est pas à ton gout mais ça ne veut pas dire que c'est une technologie dépassée
Delphi est parfaitement au gout du jour et continue d'évoluer tous les ans et reste dans "l'état de l'art" (avec ses forces et faiblesses tout comme les autres langages)
Maintenant si ta boite utilise une version vieille d'y a 15 ans, évidement dans ce cas...

Citation Envoyé par smarties Voir le message
En plus ils utilisent une façon de nommer obsolète : les noms des champs et tables en BDD doivent avoir une longueur fixe : l'avantage est que l'on fait des requêtes bien alignées, l'inconvénient on a des abréviations maisons sur tout.
C'est plutôt la culture d'entreprise qui semble dépassée dans ce cas... Pas le langage....
J'en ai connais qui sont restés bloqués sur Paradox (et ils y sont toujours)... Pas par manque de moyens mais par facilité ou faiblesse intellectuelle (ça marche alors on touche pas) du coup tu ne peux pas faire évoluer les outils de développement, ça rejoint la dette technique

Citation Envoyé par smarties Voir le message
Il y a aussi un framework interne avec 0 documentation (et on ne peut pas utiliser les commentaires DocXML), des restrictions sur les composants que l'on peut utiliser (par exemple je ne peux pas utiliser un TDictionary pour avoir des associations clé-valeur, je dois toujours utiliser des TStringlist et convertir si ce n'est pas une chaine).
Ça rejoint ce que je disais au-dessus, pas la peine qu'ils passent sur Delphi 11 (qui vient de sortir) s'ils n'utilisent pas les nouvelles possibilités, tu auras toujours l'impression d'une technologie dépassée car la puissance et la rapidité de codage offerte par de nouvelles classes te seront interdites à jamais.

Quant au Frameworks maison, je viens d'en avoir aussi une mauvaise expérience avec QT, un client a développé son propre framework métier et tient absolument à ce qu'on l'utilise mais il a été codé avec les pieds, au lieu de tirer parti de la puissance du framework QT ils ont réimplémenté des classes à leur sauce qui sont plus limités et moins efficaces que certaines classes QT...

Mais je dis pas que QT est dépassé pour ça.
C'est juste qu'ils ne savent exploiter toutes les classes existantes et ils les réinventent en y mêlant du code métier !
Bref, même si c'est à peu prés documenté, c'est dégueulasse et ça fonctionne pas au top

Citation Envoyé par smarties Voir le message
Je suis là que pour pisser du code, ils sont exigeants sur la qualité. Donc je suis en train de chercher autre chose car leurs méthodes de travail sont usantes et je n'ai pas envie de m'investir (0 avantages à côté qui pourrait motiver).
A priori, ceux qui ne sont pas restés ont eu sans soucis une rupture conventionnelle donc je vais voir pour ça.
Tu avais évoqué plusieurs fois ce problème dans des précédents posts il me semble... et rien n'a changé depuis...
4  0 
Avatar de Jeff_67
Membre éprouvé https://www.developpez.com
Le 02/10/2021 à 8:11
La dette technique n'est jamais que la partie immergée de l'iceberg. Le vrai problème de l'IT est d'être un domaine très largement tertiarisé où seules les résultats a très court terme importent.
3  0 
Avatar de eric44000
Membre régulier https://www.developpez.com
Le 02/10/2021 à 2:06
Citation Envoyé par Obsidian Voir le message
… ou alors, il faut accepter de faire du code jetable.

Ça peut être une approche, à condition de bien jeter le code à la date convenue ! Il arrive encore trop souvent que l'on se dise « bon, ben finalement, ça fait x années que ce bricolage rend service, donc on considère que c'est acquis. ».
C'est tout l'art de l'estimation des charges. La dette doit être prise en compte lors du chiffrage. On sait que sur tel type de projet on planifie un pourcentage de jour*homme pour le dév et un autre pourcentage de j*h pour une révision du code (dette technique). Ce travail doit être fait en amont.
Pas besoin de tout réécrire. Si une dette n'a que peu d'intérêt (financier), alors réécrire coûte plus cher.
2  0 
Avatar de smarties
Membre éprouvé https://www.developpez.com
Le 02/10/2021 à 9:58
L'entreprise dans laquelle je suis utilise des technologies dépassées à mon goût : Delphi
En plus ils utilisent une façon de nommer obsolète : les noms des champs et tables en BDD doivent avoir une longueur fixe : l'avantage est que l'on fait des requêtes bien alignées, l'inconvénient on a des abréviations maisons sur tout.
Il y a aussi un framework interne avec 0 documentation (et on ne peut pas utiliser les commentaires DocXML), des restrictions sur les composants que l'on peut utiliser (par exemple je ne peux pas utiliser un TDictionary pour avoir des associations clé-valeur, je dois toujours utiliser des TStringlist et convertir si ce n'est pas une chaine).

Je suis là que pour pisser du code, ils sont exigeants sur la qualité. Donc je suis en train de chercher autre chose car leurs méthodes de travail sont usantes et je n'ai pas envie de m'investir (0 avantages à côté qui pourrait motiver).
A priori, ceux qui ne sont pas restés ont eu sans soucis une rupture conventionnelle donc je vais voir pour ça.
3  1 
Avatar de smarties
Membre éprouvé https://www.developpez.com
Le 04/10/2021 à 10:59
Oui sergio, j'ai évoquer ça sur un autre post. C'est en cours donc ça m'arrive d'en remettre une couche
0  0