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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Des développeurs démissionnent pour échapper aux mauvaises pratiques de codage de leurs entreprises


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    1 812
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 1 812
    Points : 50 859
    Points
    50 859
    Par défaut Des développeurs démissionnent pour échapper aux mauvaises pratiques de codage de leurs entreprises
    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 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.

    Nom : 2.png
Affichages : 18487
Taille : 23,4 Ko

    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. »

    Nom : 1.png
Affichages : 4103
Taille : 24,2 Ko

    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre averti
    Profil pro
    Inscrit en
    Septembre 2012
    Messages
    192
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2012
    Messages : 192
    Points : 311
    Points
    311
    Par défaut
    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.

  3. #3
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    … 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. ».

  4. #4
    Membre averti
    Profil pro
    Inscrit en
    Septembre 2012
    Messages
    192
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2012
    Messages : 192
    Points : 311
    Points
    311
    Par défaut
    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.

  5. #5
    Invité
    Invité(e)
    Par défaut
    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.

  6. #6
    Expert confirmé
    Homme Profil pro
    Développeur
    Inscrit en
    Août 2003
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Août 2003
    Messages : 1 259
    Points : 4 038
    Points
    4 038
    Par défaut
    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.

  7. #7
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 353
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 353
    Points : 1 417
    Points
    1 417
    Par défaut
    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...

  8. #8
    Expert confirmé Avatar de sergio_is_back
    Homme Profil pro
    Responsable informatique, développeur tout-terrain
    Inscrit en
    Juin 2004
    Messages
    1 076
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Responsable informatique, développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 076
    Points : 5 541
    Points
    5 541
    Par défaut
    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...

  9. #9
    Expert confirmé
    Homme Profil pro
    Développeur
    Inscrit en
    Août 2003
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Août 2003
    Messages : 1 259
    Points : 4 038
    Points
    4 038
    Par défaut
    Oui sergio, j'ai évoquer ça sur un autre post. C'est en cours donc ça m'arrive d'en remettre une couche

Discussions similaires

  1. Réponses: 1
    Dernier message: 25/05/2021, 01h31
  2. Recherche des Développeurs Web pour une enquête métier.
    Par giraphe dans le forum Interviews
    Réponses: 0
    Dernier message: 26/01/2021, 14h30
  3. Réponses: 2
    Dernier message: 20/04/2019, 15h07
  4. Réponses: 12
    Dernier message: 10/04/2016, 23h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo