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

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 ?