larlet-fr-david/david/stream/2018/04/11/index.md

title: Arnaqueur senior

> 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é.
>
> Je suis bien convaincu que cette façon de faire a une certaine valeur, mais *j'ai l'impression d'être allé trop loin*. Le déséquilibre qualité / productivité est trop important (le terme *qualité* étant à comprendre comme un terme technique, je ne m'envoie pas des fleurs).
>
> Après tout, si d'un point de vue *purement technique*, il est impossible de faire de la sur-qualité, un projet, c'est aussi des contraintes temporelles, stratégiques, commerciales, économiques, etc.
>
> Faut-il revenir à une écriture de code un peu moins *pesante*, quitte à refactoriser plus et plus souvent ?
>
> <cite>*[Qualité vs. productivité](https://www.miximum.fr/blog/qualite-productivite/)* ([cache](/david/cache/3162dca46b9057f5366599de4b83333d/))</cite>

Sujet difficile et je partage de manière récurrente — pour ne pas dire quotidienne — ces interrogations sur ma pertinence lors de mon implication sur un produit. Je ne pense pas coder plus rapidement aujourd’hui qu’il y a dix ans, les outils ont évolué mais les pratiques aussi et au final la vélocité acceptable est peut-être la plus constante (car elle est indirectement reliée au revenu et que l’on a besoin de solvabilité ? Je digresse…).

En revanche il y a deux points qui me semblent faire la différence et dont j’ai bien plus conscience de l’importance aujourd’hui :

1. **Le développement le plus rapide est celui que l’on n’a pas à faire en premier lieu.** Ça semble super évident énoncé ainsi et pourtant… si je fais un bilan je suis probablement un développeur -10x ayant aligné 10 fois plus de lignes de code sans aucun intérêt pour l’utilisateur. Ici des approches comme *Lean* ou un *Product Owner* qui habite son rôle font la différence en amont afin de réduire le périmètre et d’augmenter la valeur de ce qui est développé. La réactivité et le détachement vis-à-vis du code sont aussi essentiels pour ne pas s’entêter dans une impasse.
2. **La qualité devrait être ajustable en fonction du contexte.** On ne code pas de la même manière un prototype avec une espérance de vie de trois mois et un produit qui est là pour durer. On ne se met pas les mêmes contraintes sur une application critique et sur un outil de commodité. On n’a pas les mêmes besoins de résilience en fonction du public visé, avoir une approche dogmatique est potentiellement néfaste au produit. Ici peu de pistes, les outils issus de l’agilité permettent de s’adapter à l’instant *t* et *t+1* mais il est difficile de s’attaquer à *t-1* lorsque le changement de contexte nécessite une évolution de la qualité. La dette technique est la résultante d’un manque de clarté et de rattrapage sur ce contexte changeant. On peut surévaluer le besoin pour limiter la casse mais cela se fait bien souvent au détriment de la vitesse, impossible de prédire laquelle de ces options sera la plus pertinente pour la suite de la vie du produit.

Pour en revenir à l’interrogation de Thibault, j’ai choisi l’option de la prise de recul. À savoir être frugal d’un côté en n’acceptant de ne coder que le nécessaire et lâcher-prise de l’autre en s’adaptant aux besoins. C’est ce dont j’essaye de me convaincre pour réduire ma culpabilité de développeur 10x plus humble (et âgé :-p), ma route est encore longue pour réussir à mettre en pratique une telle sagesse.

*Si vous voulez que l’on fasse un petit bout de chemin ensemble, je suis [bientôt disponible](http://larlet.com/). Et soudain le titre prend tout son sens, aheum.*

Franck a répondu avec le [Club des vieux codeurs](https://open-time.net/post/2018/04/12/Club-des-vieux-codeurs) ([cache](/david/cache/9386a26537a97cbc2e4accd2e2bdde7e/)).