Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

CoqBlog

.NET is good :-)
{ Blog de Gaël Covain }

Actualités

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 ?

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: vendredi 17 août 2007 23:31 par coq
Classé sous :

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- [Refactoring] ReSharper pour Visual Studio 2010 (Preview) par Thomas Jaskula le il y a 9 heures et 9 minutes

- [Refactoring] Analyser vos exceptions avec ReSharper Exceptional par Thomas Jaskula le il y a 10 heures et 23 minutes

- SharePoint 2007 : patterns & practices SharePoint Guidance par Philippe Sentenac [MVP SharePoint] le 07-03-2009, 09:56

- [Visual Studio 2010] Les tests cases c’est bien, mais je vais devoir tout réécrire ? par Etienne Margraff le 07-03-2009, 09:00

- MVP[Gribouillon].AddYear par The Grib's Lair [Sébastien PICAMELOT - MVP SharePoint] le 07-03-2009, 08:45

- Clinique INSIA - Projet de fin d’Etudes (Silverlight 3 MVVM et OutOfBrowser, WCF, TFS) - Part 1 par David REI le 07-02-2009, 23:38

- C’est la crise ? Bah pourquoi cramer du budget pub alors ? par Nix's Blog le 07-02-2009, 15:31

- Soyons MVP ! par TheSaib .NET blog le 07-02-2009, 12:15

- SharePoint : Gestion des Erreurs 6398, 7076 et 6482 par Blog Technique de Romelard Fabrice le 07-02-2009, 11:53

- EF avec WPF par Matthieu MEZIL le 07-02-2009, 10:18