CoqBlog

Post sympa : Fire your best people…reward the lazy ones

En voilà un post sympathique, si seulement ce mode de pensée était suffisamment répandu...
Je ne parle pas des licenciements naturellement, mais de la prise en compte des problèmes qui n'arrivent pas au lieu de seulement prendre en compte la vitesse de résolution de ceux qui arrivent.
Se rendre compte que ce paresseux (dans le bon sens du terme) est peut être au final plus productif que celui qui résout tous les problèmes avec brio mais n'essaie pas de les prévenir... Attention, il en faut quand même des experts (les "troubleshooter") comme cela, ne nous méprenons pas ! Le mieux serait encore de réussir à les rendre paresseux, de les convertir en "troublepreventor" (je l'aime bien ce terme là)...
Le paresseux ? Mais si, vous savez, celui que vous voyez de temps à autre "perdre" son temps à tapoter des scripts pour automatiser une manipulation, une vérification, ... pourtant si courte, et qu'on ne fait pas si souvent que ça... en théorie... seulement la théorie... c'est la théorie... Bon naturellement par la suite ce qui ne se voit pas c'est le temps qu'il va gagner, vu que justement il ne fera rien, ou plutôt dans le cas du bon paresseux, il va faire autre chose... Et peut être même acquérir un peu plus l'expertise nécessaire à la résolution des problèmes inévitables, vu qu'au fond le "troublepreventor" est un peu (beaucoup) "troubleshooter", mais il préfère éviter d'avoir à se servir de cette partie là de ses compétences.

Pour prendre un exemple : le cas de l'encoding des scripts sql dont je parlais la dernière fois, le type de problème qui ne provoque pas d'erreur immédiate mais entraine une corruption des données.
Si jamais le problème ne se voit pas tout de suite, qui pensera encore dans un mois que c'est justement une donnée manipulée par le script ?
Si l'application est une application web, qui pensera alors qu'il faut d'abord chercher du côté de la base avant de regarder si ce n'est pas un problème avec l'interface web en elle même qui provoque l'affichage de ce sympathique 'Ù' ?
Un problème est identifié, la parade est trouvée, mais qui va penser à vérifier à chaque nouveau script qu'il a bien été enregistré dans le bon encoding ?
Le premier jour : tout le monde ou presque.
La semaine suivante : presque plus personne.
Bien sûr, si le 'Ù' revient un jour, on saura sans doute identifier plus rapidement la cause... du moins, si la connaissance a été partagée, et si les personnes la possédant sont toujours dans les parages.
Alors qu'avec les quelques (dizaines de) minutes perdues par le paresseux, la vérification peut être effectuée à volonté, et même automatisée.

Dans le même ordre d'idée, il aura probablement tendance à concevoir et développer la solution en gardant à l'esprit que la prochaine étape, c'est la maintenance, qu'il y aura forcément des ajustements, des évolutions, ...
Comment ? Haaaaa non, peu importe l'estime que l'on se porte, nous ne sommes pas infaillibles ! Nous ne devons pas produire un code en pensant que nous n'aurons jamais à y revenir, et il faut même justement le produire pour que quelqu'un d'autre puisse y revenir, ce qui sera probablement le cas. Ce qui amène naturellement au dernier sujet qui fâche, la documentation : prendre des notes durant le développement, même sans mise en page stricte dans un premier temps, afin de pouvoir les partager (et même s'y référer soit même : qui ne s'est jamais demandé pourquoi il avait fait une chose telle qu'elle l'a été) et que le prochain sur le projet ne parte pas de zéro.
Si quelques jours gagnés d'un côté entrainent des semaines de pertes de temps d'un autre, est ce vraiment rentable ?