Quand on se fait agent du changement vers des pratiques de développement agiles, on se fait rapidement traiter de fanatique et c’est effectivement ce que l’on a l’air d’être. Je ne sais pas comment font les autres, mais personnellement j’utilise l’idéal comme une référence et une vision de l’objectif à atteindre. Il n’est pas si facile de garder le cap quand on est plongé dans la réalité. Voici ce qu’un client a pu dire de moi dernièrement :

L’effet des commentaires sur l’interprétation d’un code contenant des erreurs L’effet des commentaires sur l’interprétation d’un code contenant des erreurs peut être mesuré assez élégamment par une expérience dans laquelle plusieurs versions d’un même code est produite, une avec des commentaires corrects, une avec un ou deux commentaires incorrects, et une sans aucun commentaire (Okimoto, 1970). Pour certains types de code, au moins, l’interprétation correcte de ce que fait le programme peut être obtenue avec plus de fiabilité et plus rapidement sans commentaire du tout.

Voici quelques remarques générales sur les commentaires de programme. Cet essai a été écrit suite à la lecture du poste de Christian Faure sur la litterature de code. Comme le fait remarquer Christian Faure dans une réponse à ce message, il s'agit ici du point de vue d'un développeur professionnel. D’une manière générale, je réduis les commentaires au minimum car ils constituent une forme de duplication d’avec le code écrit juste à coté.

Mettre en place un projet de développement logiciel, c’est réunir d’une part des gens qui ne savent pas ce qu’ils veulent (experts fonctionnels) et d’autre part des gens qui ne savent pas comment faire (experts techniques). A la fin du projet, chacun en aura appris un peu plus sur son métier.

Non ! Encore cette étiquette d’extrémistes ! Comment Schumacher aurait-il pu gagner un championnat de formule 1 s’il n’appuyait pas au maximum sur l’accélérateur ? Voila l’idée de l’eXtreme Programming. Il ne s’agit pas d’aller trop loin, mais de rechercher la performance optimum des pratiques qui la constituent. Il ne faut pas croire que eXtreme Programming signifie extrême effort, ou horaires extrêmes. Il s’agit en fait d’optimiser la méthode de travail. Quel effort y-a-t’il à pousser sur l’accélérateur jusqu’à sa position idéale ?

Un programmeur qui travaille sans tests automatisés est comme un aveugle qui construit un château de cartes. C’est pour ça qu’il devient tout blanc quand le client vient le voir pour une modification tardive des exigences fonctionnelles.

From Quality Software Management: congruent action (p125), by Gerald Weinberg, about the variety-reducing style of management: …As we used to say, developers were treated like ‘coding cattle’. If you weren’t a good producer, they would get rid of you. Presumably, you were transformed into meatballs for serving with spaghetti code.

A partir du moment où la méthode de travail embrasse le changement, il n’est plus la peine de se préparer autant avant de commencer. Que de temps gagné sur la longue phase d’écriture des spécifications.

J'ai assisté aux rencontres agiles 2007 qui se sont déroulées de 9h00 à 12h00 mardi 18 décembre à Paris La Défense. Pour commencer, une petite déception personnelle, en effet, cette conférence était plutôt orientée “newby” du fait de son format : des présentations nombreuses et courtes (20 minutes). Malheureusement, la présentation de Christophe Thibaut a sauté. J’ai été content de voir une présentation de Claude Aubry et de Christophe Addinquy que je ne connaissais pas.

Par Christophe Porteneuve, éditions Eyrolles J’ai gagné ce livre lors du séminaire XP Days. Je n’ai pas encore eu le temps de le lire entièrement (et puis je ne suis pas développeur Web alors j’avance lentement). Ce livre plutôt épais contient apparemment énormément (tout ?) de choses sur les technologies du Web 2.0. Mais ce n’est pas simplement un livre de description de technologies, c’est aussi un livre sur la technique de programmation en général, et sur le métier de développeur Web en particulier.