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 :

Le nombre d’heures passées sur un code reflète-t-il le degré d’implication du développeur ?


Sujet :

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

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Étudiant
    Inscrit en
    Août 2011
    Messages
    283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Août 2011
    Messages : 283
    Points : 18 071
    Points
    18 071
    Par défaut Le nombre d’heures passées sur un code reflète-t-il le degré d’implication du développeur ?
    Le nombre d’heures passées sur un code reflète-t-il le degré d’implication du développeur ?
    Un développeur senior s’interroge

    Alors qu’il est relativement simple de constater qu’une personne travaille dur lorsqu’il s’agit d’un travail physique ou encore d’un sport, comment est-il possible de juger si une personne s’implique dans son travail lorsqu’il s’agit d’une activité mentale, comme dans le cas des développeurs ?

    C’est la question posée par le développeur senior Mike Shadlow dans un billet de blog, où il revient entre autres sur une de ses expériences personnelles, qui se déroule en 2004 au sein d’une large équipe de développeurs travaillant sur un système de facturation et d’approvisionnement pour des chaînes télévisées.

    Au cours de cette expérience, Mike Shadlow a été affecté à l’équipe chargée du développement du système relatif à la chaine numérique. En parallèle, une seconde équipe se chargeait de la chaine analogique. Mis à part ces différences, les deux équipes étaient chargées de concevoir le même système.

    Toutefois, alors que l’on pourrait penser que les deux équipes allaient avoir la même approche, cela n’a pas été le cas. La conception du système pour la chaine numérique a été effectuée dans l’ensemble par un développeur ayant adopté les préceptes de la programmation orientée objet, les principes SOLID ainsi que les tests unitaires.

    La lecture du dit code semblait une tâche ardue aux premiers abords, mais grâce aux conseils avisés de son concepteur, Mike Shadlow a pu se documenter et étudier les bases sur lesquelles reposait le code. Dès lors, tout devenait clair et sensé. Le développement du code fut relativement une tâche facile et concise, sans retard, surprise ou difficulté et les développeurs n’ont pas eu à effectuer des heures supplémentaires.

    Du côté de la seconde équipe, les choses étaient complètement différentes. Le développement du système s’était montré plus complexe et difficile, le code était moins stable, les développeurs étaient confrontés à plusieurs bugs. Il était alors possible de les voir se réunir autour du bureau de l’un des développeurs essayant en vain d’élucider le problème. La tâche était si chronophage que les développeurs travaillaient durement jusqu’à des heures tardives ou encore lors des week-ends.

    Alors, lorsqu’il était question de jauger le sérieux, le degré d’implication des développeurs issus des deux équipes, sur une perception purement temporelle, il était clair que la seconde équipe montrait une plus grande implication, mais était-ce la vérité ?

    Le semblant de paresse et de non-implication de la 1ère équipe contrastait beaucoup avec celui de la deuxième équipe. Néanmoins, cela ne signifiait pas une moindre implication dans le fond, mais plutôt une capacité à travailler de manière efficace et sans trop d’effort, travailler peu et bien au lieu de trop pour peu.

    Au final, cette situation montre clairement qu’il est difficile de juger le travail d’un développeur sur un plan purement temporel ou encore en observant l’agitation des développeurs au sein de l’espace de travail. Il est donc plus judicieux de s’accorder sur une approche plus décalée pour juger du sérieux du développeur en tenant compte de la qualité du code et du temps passé à la bonne conception du logiciel, ce qui débouche généralement sur un travail efficace.

    Source : blog de Mike Shadlow

    Et vous ?

    Qu’en pensez-vous ?

  2. #2
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2008
    Messages
    176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : Avril 2008
    Messages : 176
    Points : 372
    Points
    372
    Par défaut
    J'en pense que ça reflète bien ce qui se passe dans ma boite.

    Pour un résultat égal, on préfèrera un développeur moyen qui fera beaucoup d'heure sup. qu'un bon développeur faisant ses heures (sic mon chef de projet ) car il donnera l'impression de plus s'investir ...

  3. #3
    Membre expert

    Développeur NTIC
    Inscrit en
    Janvier 2011
    Messages
    1 670
    Détails du profil
    Informations personnelles :
    Âge : 33

    Informations professionnelles :
    Activité : Développeur NTIC
    Secteur : Biens de consommation

    Informations forums :
    Inscription : Janvier 2011
    Messages : 1 670
    Points : 3 942
    Points
    3 942
    Par défaut
    Qu’en pensez-vous ?
    Le code n'est que la finalité, le plus important étant surtout de savoir réceptionner et comprendre le besoin client, puis de le retranscrire. Et c'est sur cette retranscription que s'appuiera le code.
    L'homme est un fou pour l'homme. Toi qui viens de me mettre un aie au moins le courage d'expliquer pourquoi tu n'es pas d'accord.

  4. #4
    Membre actif
    Profil pro
    Inscrit en
    Février 2007
    Messages
    217
    Détails du profil
    Informations personnelles :
    Âge : 31
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 217
    Points : 228
    Points
    228
    Par défaut
    Ce qu'il faut c'est bien comprendre les besoins du clients, et bien concevoir l'architecture pour avoir un minimum de changements une fois le codage commencé.
    Et le mieux c'est de faire en sorte que tout le monde comprenne l'architecture, et quelle est la logique derrière.

    Rien ne sert de pondre 40 000 lignes alors que 10 000 suffisent...

  5. #5
    Invité
    Invité(e)
    Par défaut
    Ça me fait penser à ce commentaire :

    //
    // Dear maintainer:
    //
    // Once you are done trying to 'optimize' this routine,
    // and have realized what a terrible mistake that was,
    // please increment the following counter as a warning
    // to the next guy:
    //
    // total_hours_wasted_here = 42
    //

  6. #6
    Membre expert

    Développeur NTIC
    Inscrit en
    Janvier 2011
    Messages
    1 670
    Détails du profil
    Informations personnelles :
    Âge : 33

    Informations professionnelles :
    Activité : Développeur NTIC
    Secteur : Biens de consommation

    Informations forums :
    Inscription : Janvier 2011
    Messages : 1 670
    Points : 3 942
    Points
    3 942
    Par défaut
    Citation Envoyé par chanyslas Voir le message
    Ça me fait penser à ce commentaire :

    //
    // Dear maintainer:
    //
    // Once you are done trying to 'optimize' this routine,
    // and have realized what a terrible mistake that was,
    // please increment the following counter as a warning
    // to the next guy:
    //
    // total_hours_wasted_here = 42
    //
    J'ai pour idée de mettre celui là en commentaire d'un code pourri (modifié pour l'occasion ^^) :

    - I don’t know who you are. I don’t know what you want. If you’re looking for a ransom, I can tell you I don’t have money, but what I do have are a very particular set of skills, skills I have acquire over a very long career, skills that make me a nightmare for people like you. If you let my me go now, that will be the end of it. But if you don’t, I will look for you, I will find you, I will kill you.
    - Good luck.
    L'homme est un fou pour l'homme. Toi qui viens de me mettre un aie au moins le courage d'expliquer pourquoi tu n'es pas d'accord.

  7. #7
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2010
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Septembre 2010
    Messages : 25
    Points : 58
    Points
    58
    Par défaut
    Complétement d'accord avec ce développeur. Bien trop souvent, on considère dans l'entreprise que seul le temps passé sur un projet rime avec sérieux et implication. Or, un "bon" développeur cherche à faire du code réutilisable dans d'autres modules/projets, et produit un code "propre". Au final, il économise du temps pour ses futurs dev similaires, et s'épargne une maintenance douloureuse. Effectivement, les heures suppl et les WE travaillés bénévolement ne sont pas forcement légion, et ça fait moins d'effet auprès de la Direction ...

    Dans la même veine, il y a aussi le piège du développement vite-fait bien fait : en réussissant à livrer dans les temps une version qui fait ce qu'on lui demande sans que ça plante, on donne l'impression que la tâche était facile. Si la personne qui supervise n'a pas un minimum de connaissances techniques, elle en conclura que le boulot ne posait aucune difficulté, et n'hésitera pas lors de la prochaine demande à augmenter le nombre de points à corriger/développer pour le dév en question.

    Après c'est un peu comme ça un peu partout, le gars qui finit à l'heure sera toujours suspecté d'être fainéant et/ou d'en faire moins que les autres ...

  8. #8
    Membre éprouvé Avatar de Shuty
    Homme Profil pro
    Ingénieur en développement
    Inscrit en
    Octobre 2012
    Messages
    630
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur en développement
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 630
    Points : 1 174
    Points
    1 174
    Par défaut
    Le travail de développeur n'est pas un travail de quantité mais plutôt de qualité.
    Agence web Dim'Solution, créateur de solutions numériques
    Sites internet, ecommerce, logiciels, applications mobiles, référencement (SEO), plugin Prestashop, Magento, WordPress, Joomla!...

    Cours de trading gratuit | Envoyer des sms gratuitement | Envoyer des fax gratuitement | Plateforme de Fax à l'international

  9. #9
    Membre expérimenté Avatar de Uranne-jimmy
    Homme Profil pro
    Bioinformatique
    Inscrit en
    Décembre 2012
    Messages
    778
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Bioinformatique
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Décembre 2012
    Messages : 778
    Points : 1 461
    Points
    1 461
    Par défaut
    Malgré tout, l'exemple étudié ne rend pas compte de l'implication du développeur mais plutôt de sa capacité à faire les bons choix.
    Par nature, j'ai l'impression qu'une bonne partie des développeurs préfèrent travailler intelligemment que beaucoup, ce qui se conçoit facilement dans le sens où ils font des logiciels dans ce sens. A partir de là, un bon dév ira au plus court et au moins fatiguant (à long terme) au but établi, produira un code stable, lisible et efficace. Mais on peut très bien être appliqué, travailler sans compter, s'investir sans avoir les capacités d'un bon développeur (notion idyllique, je ne prétend pas savoir qui est bon et qui est mauvais).
    Ce que je vois dans l'exemple cité c'est une équipe organisé, préparé, qui connait les bons outils au moins de réputation, et une équipe sincère, travailleuse, qui ne connait pas ou n'a pas pour habitude de se baser sur les outils les plus adaptés.

    A mes débuts, j'ai voulu utiliser les langages que je connaissais le mieux en dépit de la charge supplémentaire de travail que cela demandé par rapport à un langage plus adapté, pensant que justement l'expérience réduirait le temps nécessaire à mes fins, je me suis trompé et maintenant je fais autrement. Du coup ce cas me rappelle un peu moi, et je ne vois nul par de rapport avec l'implication du dév.
    Expert en recherche google caféinomane

  10. #10
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2011
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2011
    Messages : 50
    Points : 194
    Points
    194
    Par défaut
    Citation Envoyé par Shuty Voir le message
    Le travail de développeur n'est pas un travail de quantité mais plutôt de qualité.
    et de méthode surtout, éviter de réinventer la roue grâce à l'usage de frameworks de développement,

    et l'application de certains concepts pour fiabiliser/rationaliser le code ( programmation orientée objet, design patterns )

  11. #11
    Membre du Club
    Profil pro
    Inscrit en
    Août 2007
    Messages
    45
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 45
    Points : 65
    Points
    65
    Par défaut
    Remplacez le mot "code" par le mot "maison" et cela fonctionne.
    Préférez-vous une maison bien construite ou un truc où les briques ne sont pas alignés, plein de tranchés pour réparer les oublis...

  12. #12
    Membre actif
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    182
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Avril 2009
    Messages : 182
    Points : 268
    Points
    268
    Par défaut
    Vaut mieux travailler un nombre d'heure respectable et concentrer 100% ses efforts sur l'objectif de l'itération que de travailler 50 heures semaines et faire du refactoring un peu partout dans le code et introduire plein de possible nouveaux bugs. tout le monde connais quelqu'un qui push à tout les 20 minutes. C'est noble d'être aussi passionné et de vouloir amiliorer l'état du code mais moi perso je préfere concentrer 100% des mes efforts sur le sprint que sur des trucs qui sont "out of scope".

  13. #13
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2014
    Messages
    345
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : Juin 2014
    Messages : 345
    Points : 1 211
    Points
    1 211
    Par défaut
    Citation Envoyé par javan00b Voir le message
    Vaut mieux travailler un nombre d'heure respectable et concentrer 100% ses efforts sur l'objectif de l'itération que de travailler 50 heures semaines et faire du refactoring un peu partout dans le code et introduire plein de possible nouveaux bugs.
    Ça dépend de la taille du projet. De mon expérience, quand on travaille sur un projet impliquant de nombreuses personnes et sur une longue durée, le refactoring est "rentable".
    Parce que sans refactoring le mec qui fait la maintenance finit très vite par s'arracher les cheveux.

  14. #14
    Membre régulier Avatar de thetrollman
    Homme Profil pro
    Inscrit en
    Juillet 2013
    Messages
    60
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations forums :
    Inscription : Juillet 2013
    Messages : 60
    Points : 107
    Points
    107
    Par défaut
    Le nombre d'heures n'a rien a voir.
    Y'en a qui code un peu plus vite que les autres et leurs codes sont bons. Et le contraire aussi est possible travaille plus mais la qualité du code est meilleur. Chacun à sa façon de coder. D'autre travailles mieux avec une semaine routinière avec des heures et pause fixe et d'autre non. La qualité n'a rien a voir. Chaque personnes pensent différemment et a sa façon a lui de travailler.

    Y'a pas d’équation qui marche c'est pas si + 50 heure pour projet = the best code.

  15. #15
    Membre habitué
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2014
    Messages
    70
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2014
    Messages : 70
    Points : 180
    Points
    180
    Par défaut Comment nous voit les entreprises
    Le problème, c'est que les entreprises voient le développement d'une appli comme ça :
    http://www.commitstrip.com/fr/page/70/
    No comment...
    Nous serons en danger le jour où les machines seront capable de glander.

  16. #16
    Membre habitué
    Homme Profil pro
    Directeur Recherche et développement
    Inscrit en
    Janvier 2012
    Messages
    58
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur Recherche et développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2012
    Messages : 58
    Points : 156
    Points
    156
    Par défaut
    Pour moi, la valeur d'une équipe de développement est celle qui réussit à atteindre la satisfaction du client en faisant le moins d'effort. Peu d'effort implique un haut degré de design et un haut degré de réutilisation des codes générés. Moins qu'il a de lignes dans votre code et plus la réutilisation est grande, moins il y a de possibilité d'erreur et s'il en a, les erreurs sont plus facile à trouver car il y a moins de ligne...
    Malheureusement, il est difficile pour l'administration de mesurer cela. Plus la hiérarchie administrative et de gestion d'une entreprise est importante, plus on aura tendance à valoriser le surtemps et des métriques inadaptées...
    Pour ma part, l'adage diviser pour régner n'est pas seulement pour le logiciel mais aussi pour l'ensemble de la structure de gestion de la compagnie. Diviser n'est pas de multiplier la hiérarchie de gestionnaires mais de permettre à chacun d'être le gestionnaire d'un domaine donné en fonction de ses compétences et ses intérêts. Les décisions sont alors collégiales et non imposé par la hiérarchie. Un environnement bien plus valorisant et stimulant pour tous. Par expérience, chacun se sent impliqué et il est bien plus productif.

  17. #17
    Membre habitué Avatar de robinsondesbois
    Homme Profil pro
    Etudiant
    Inscrit en
    Avril 2012
    Messages
    171
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Haute Loire (Auvergne)

    Informations professionnelles :
    Activité : Etudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2012
    Messages : 171
    Points : 173
    Points
    173
    Par défaut
    Sur une méthode AGILE il est plus rapide de recommencer le projet quand on commence à avoir du sparadrap sur du sotch pour que des bug ne tombe pas.

  18. #18
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Je rajouterais deux adages que j'ai entendu de la part de développeurs plus expérimentés que moi

    Un bon développeur est un développeur feignant: il réfléchira une minute de plus pour tapez une touche de moins
    Là, on reprend bien sur l'idée d'éviter de réinventer la roue, mais aussi de tout les petits outils qu'une équipe va se réaliser pour éviter les taches rébarbative.
    Sur ce dernier point, les équipes d'administrations systèmes sont très fort: mettre au point des scripts intelligents pour faire le boulot à sa place et mieux.

    Développez une nouvelle fonctionnalité en imaginant que la personne qui maintiendra votre code sera un psychopathe meurtrié qui connait votre adresse.
    Là, si on applique cela, la qualité de notre code atteint des sommets

  19. #19
    Membre confirmé

    Homme Profil pro
    Consultant en architecture
    Inscrit en
    Décembre 2013
    Messages
    82
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant en architecture
    Secteur : Conseil

    Informations forums :
    Inscription : Décembre 2013
    Messages : 82
    Points : 562
    Points
    562
    Billets dans le blog
    1
    Par défaut
    La bonne question à se poser est "quels sont les indicateurs mesurables (relativement simplement) qui permettent d'évaluer la qualité du travail fourni?"

    Mettons-nous à la place du chef de projet : comment peut-il savoir le temps/la charge qu'aurait dû mettre une équipe pour faire le projet? Comment peut-il savoir à l'avance si le code va être facilement maintenable, et peu buggé?
    Si il voit son équipe réaliser un projet en 3 mois, alors qu'une équipe "moyenne" l'aurait fait en quatre (ou deux), comment peut-il s'en rendre compte et faire la différence entre les bons et les mauvais chasseurs développeurs?

    Déterminer la performance d'une équipe de développeurs nécessite de savoir le temps qu'aurait du mettre l'équipe sur un projet, le nombre de bugs auxquels ont devrait pouvoir s'attendre, la "facilité" à modifier l'existant, et ce en fonction du contexte (changement de spécifications à la dernière minute, contraintes technologiques...) Malheureusement, le seul moyen que je connais pour savoir ça vient de l'expérience des manager/chefs de projet, et je ne suis pas sûr que ça soit tellement plus fiable pour évaluer la performance que le temps passé sur sa chaise

    La question du (des?) bon(s) indicateur(s) qui permettra(ont) d'identifier la performance et le degré d'implication d'un dev reste ouverte

  20. #20
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 347
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 347
    Points : 20 347
    Points
    20 347
    Par défaut
    Citation Envoyé par matpush Voir le message
    J'en pense que ça reflète bien ce qui se passe dans ma boite.

    Pour un résultat égal, on préfèrera un développeur moyen qui fera beaucoup d'heure sup. qu'un bon développeur faisant ses heures (sic mon chef de projet ) car il donnera l'impression de plus s'investir ...
    mouais et qui passe son temps à surfer sur Internet...

    le stakhanovisme c'est dépassé ; passe encore si tu est nouveau dans une entreprise et que tu est en phase d'apprentissage.

    Sinon si tu travailles plus que prévu c'est que ton travail n'est pas rentable financièrement , soit que tu ne sais pas t'organiser et faire de la refactorisation de code comme mentionné très bien avant, soit que le travail à effectuer est trop laborieux et rapporte peu au final d'un point de vue économique

Discussions similaires

  1. [AC-2003] Création d'un code pour ajouter un mot de passe sur le bon identifiant.
    Par Chagui dans le forum VBA Access
    Réponses: 6
    Dernier message: 21/10/2010, 20h30
  2. Demander un mot de passe sur "Créer code événement"
    Par FrankOVD dans le forum Sécurité
    Réponses: 1
    Dernier message: 20/01/2010, 16h21
  3. j'ai oublié mon mot de passe sur le code VBA
    Par KOUADIO SEVERIN dans le forum Access
    Réponses: 1
    Dernier message: 16/07/2008, 23h40
  4. mot de passe sur code VBA
    Par Cupidon dans le forum VBA Access
    Réponses: 4
    Dernier message: 07/02/2007, 16h05
  5. [Conception] Question sur un code permettant de connaître le nombre de connectés
    Par inferno66667 dans le forum PHP & Base de données
    Réponses: 11
    Dernier message: 19/12/2005, 20h49

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