Julien Carnelos Blog – Archives

Dans le livre Peopleware, le chapitre « Making change possible » parle de la difficulté à faire changer les choses dans un projet (aspect aussi bien technique que méthdologique).

J’ai à plusieurs reprises travaillé avec des équipes ayant un niveau de technicité différent.Par exemple, des équipes travaillant sans un gestionnaire de sources.

Ma première réaction est l’étonnement :

Mais comment pouvez vous travailler avec des conditions pareilles ?

(Si l’on y réfléchit, on peut très bien travailler sans gestionnaire de conf, il suffit de faire plus attention c’est tout 😉 ).

Passé cette réaction, la prochaine étape est de montrer à l’équipe l’intérêt de cet outil et leur faire intégrer dans leur process de développement.

Pour cela, j’avais tendance à donner l’ensemble des avantages, dire que tout sera plus beau et bien mieux. Ce qu’on peut représenter par le schéma suivant :

 ANCIENNE FACON ==> NOUVELLE FACON

Et bien, cette technique en pratique donne de mauvais résultats (incroyable c’est le sujet de ce post)…

Par exemple, la mise en place des projets sur le gestionnaire est difficile au début, des nouveaux mots sont à maitriser pour comprendre. La syntaxe n’est pas évidente non plus et les erreurs sont fréquentes. Résultat, on passe beaucoup plus de temps à gérer ses sources, temps qui était disponible auparavant pour d’autre chose…

Au final, la réalité s’approche plutôt du schéma suivant :

 ANCIENNE FACON ==> CHAOS ==> APPRENTISSAGE ==> NOUVELLE FACON

Le passage obligé mais souvent oublié c’est l’étape chaotique où les développeurs râlent car cette nouvelle complexité ne leur apporte aucun avantage. Ils ne voient que les défauts et aucun intérêt… Cette étape difficile est souvent le moment où se repose la question cruciale :

Est-ce que vraiment ca valait le coup, parce qu’on peut encore revenir en arrière sinon !

Finalement avec un peu de volonté et de la pratique, tout le monde finit par piger le truc et cette nouvelle façon de travailler plaît !

La leçon à retenir c’est que lors d’un changement, il faut être très clair sur plusieurs points :

• Oui ça sera mieux (on y croit)

MAIS

• Il y aura une période incertaine et plus difficile dont il ne faut pas avoir peur
• Il faut accepter de sortir de notre sécurité actuelle pour tenter de nouvelles choses
• Le changement ne doit pas être un couteau sous la gorge et il faut avoir le droit à l’erreur

Je travaille avec beaucoup de développeurs qui ont commencé sur la version 1.0 ou 1.1 du framework ASP.NET.

La version 2.0 étant rétro-compatible, il n’est pas forcément évident de saisir les subtiles différences qui existent.

J’ai trouvé récemment un guide sur le site des développeurs ASP.NET qui présente justement ASP.NET 2.0 pour les développeurs qui ont connu la première version.

Je vous incite donc à le lire si vous êtes passés en .NET 2.0 !

• ASP.NET 2.0 Internals (article en anglais)

remarque : c’est encore une nouvelle catégorie : dotnet 🙂 .

Après la version Virtual Serveur, déjà offerte depuis un petit moment, la version « normale » devient gratuite à son tour.

La virtualisation devient plus que jamais une commodité et l’on peut constater que tous les acteurs ont maintenant leur version gratuite (Microsoft, VMWare…)

Pour Microsoft, c’est une stratégie intéressante qui leur permettra de vendre des licences serveur sur lesquels seront installé les machines virtuelles. Puisque évidemment, Virtual PC et Virtual Server ne fonctionnent tous deux que sur un OS Windows.

De plus, si l’OS hôte est un Windows, cela pourra encourager les administrateurs système à installer également des windows dans les machines virtuelles. Conclusion, je pense qu’ils ont refléchi à deux fois avant d’offrir gratuitement cet outil 🙂

En dehors de cet aspect serveur, il est plus que jamais interessant pour les développeurs d’avoir également des machines virtuelles afin de tester différents environnements. Par exemple, un environnement dotNET, un Java, un Ruby 😉 … ou pour tester différents OS/navigateurs web…

Lien pour télécharger Virtual PC 2004.