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 !

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

Le , par Arsene Newman

18PARTAGES

8  0 
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 ?

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

Avatar de Luckyben
Membre du Club https://www.developpez.com
Le 28/07/2014 à 12:10
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 ...
9  0 
Avatar de
https://www.developpez.com
Le 28/07/2014 à 11:46
Ç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
//
7  0 
Avatar de Shuty
Membre éprouvé https://www.developpez.com
Le 28/07/2014 à 13:29
Le travail de développeur n'est pas un travail de quantité mais plutôt de qualité.
6  0 
Avatar de Uranne-jimmy
Membre expérimenté https://www.developpez.com
Le 28/07/2014 à 13:45
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.
6  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 29/07/2014 à 10:45
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
5  0 
Avatar de matpush
Membre averti https://www.developpez.com
Le 28/07/2014 à 11:28
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 ...
6  2 
Avatar de khazna
Membre actif https://www.developpez.com
Le 28/07/2014 à 11:38
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...
4  0 
Avatar de Mc geek
Membre habitué https://www.developpez.com
Le 28/07/2014 à 18:32
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...
4  0 
Avatar de Mr_Exal
Membre expert https://www.developpez.com
Le 28/07/2014 à 11:29
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.
3  0 
Avatar de Mr_Exal
Membre expert https://www.developpez.com
Le 28/07/2014 à 11:58
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.
3  0