larlet-fr-david-cache/cache/3162dca46b9057f5366599de4b83333d/index.md

title: Qualité vs. productivité
url: https://www.miximum.fr/blog/qualite-productivite/
hash_url: 3162dca46b9057f5366599de4b83333d

<p class="lead" itemprop="headline">
    Quelques questionnements sur la relation entre ancienneté, qualité et productivité.
    </p>
    <div itemprop="articleBody">
    <p>Il y a quelques temps, j'ai posté sur Twitter une boutade sous forme de
diagramme.</p>
<figure>
<img src="https://i.miximum.fr/i/2018/04/HLI0T1AEI9.png" alt="diagrammes représentant l'évolution de la répartition de mon temps de travail avec les années."/>
<figcaption>
Plus les années passent, moins je code.
</figcaption>
</figure>

<p>À la réflexion, la situation, présentée comme une blague, n'est pourtant pas si
éloignée de la réalité.</p>
<p>J'observe des évolutions dans la manière dont je travaille.</p>
<p>J'ai commencé à coder vers le lycée. À cette époque, et pendant plusieurs
années, je me lançais dans l'écriture de code avant d'avoir réfléchi. À vrai
dire, l'écriture me servait de processus de réflexion, et je ne savais pas
vraiment ou je voulais en venir tant que je n'avais pas terminé d'écrire ma
fonction.</p>
<p>Quand je rencontrais un bug, ou que mon code ne fonctionnait pas correctement,
j'avais tendance à bidouiller « jusqu'à ce que ça marche », sans avoir de vraie
compréhension du problème.</p>
<p>« Tiens, cette partie du programme ne fonctionne pas. Et si je modifie ça ? Et
là ? Et comme ça ? »</p>
<p>Inutile de dire que d'un point de vue technique, le résultat obtenu n'était pas
terrible.</p>
<p>Avec le temps, j'ai commencé à coder <em>moins vite</em> ; à chercher à mieux
comprendre la problématique avant de la résoudre.</p>
<p>La pratique déterminante a été le passage au développement piloté par les tests
(TDD). Écrire les tests d'une fonction avant d'écrire la fonction nécessite de
sacrément bien réfléchir à <em>ce que doit faire ou ne pas faire</em> ladite fonction.</p>
<p>Avec une meilleure compréhension de ce qu'est un code fiable et maintenable
dans le temps, il était également inévitable de passer plus de temps à
refactoriser du code existant.</p>
<p>À ce moment là, je me suis aperçu que mon code était moins sujet aux bugs et
comportements inattendus.</p>
<p>J'ai remarqué que cette évolution a continué jusqu'à aujourd'hui. Je ne suis
pas précisément en fin de carrière, mais pas sans expérience non plus.</p>
<p>Maintenant, je suis tellement délicat avec mon code que je me fais l'impression
d'être un vieillard tremblotant en train de choisir une tasse dans un magasin
de porcelaine.</p>
<p>La moindre ligne nécessite un temps infini.</p>
<p>Il m'arrive parfois de passer une heure juste pour choisir un nom de variable
approprié.</p>
<p>Je pense et repense à tous les cas de figures possibles, les cas d'erreurs, les
logs, les exceptions, la performance, l'accessibilité, les conséquences à long
terme, les impacts métiers, etc.</p>
<p>J'ai souvent entendu dire qu'il était rentable d'embaucher des devs seniors
parce qu'ils pouvaient avoir 10x la productivité des juniors. J'y croyais. Mais
chez moi, ça n'en prends pas le chemin. À vrai dire, je me sens 10x moins
productifs aujourd'hui qu'avant.</p>
<p>J'ai parfois une légère tendance à succomber à la suringénieurisation.</p>
<p><em>Je ne dis pas que c'est une bonne chose.</em></p>
<p>Si je fais le point, je trouve que mon travail d'aujourd'hui est <em>vraiment</em>
beaucoup plus robuste qu'il y a dix ans. Le code sans bug n'existe pas, mais je
suis beaucoup moins souvent confronté à des comportements indésirables ou
inattendus qu'auparavant. Étonnamment, une fois le code écrit, je ne
refactorise plus tant que ça (en tout cas, moins qu'à une époque).</p>
<p>En contrepartie, je suis effaré par mon manque de productivité. Quand je
travaille pour des clients, je m'étonne parfois de ne pas être pris pour un
arnaqueur, tant il m'arrive de passer une journée à corriger un seul bug, à
réaliser une seule petite fonctionnalité.</p>
<p>Je suis bien convaincu que cette façon de faire a une certaine valeur, mais
<em>j'ai l'impression d'être allé trop loin.</em> Le déséquilibre qualité /
productivité est trop important (le terme <em>qualité</em> étant à comprendre comme un
terme technique, je ne m'envoie pas des fleurs).</p>
<p>Après tout, si d'un point de vue <em>purement technique</em>, il est impossible de
faire de la sur-qualité, un projet, c'est aussi des contraintes temporelles,
stratégiques, commerciales, économiques, etc.</p>
<p>Faut-il revenir à une écriture de code un peu moins <em>pesante</em>, quitte à
refactoriser plus et plus souvent ?</p>
<p>Il est assez facile de reconnaître sa progression, mais plus difficile de
déterminer quelle est la prochaine étape. Comment ma façon de travailler
va-t-elle évoluer ? Qu'est-ce qui me ferait passer à l'étape d'après ? Je me
pose sincèrement la question. Comment ça se passe chez vous ?</p>
    </div>