Tag Archives: livre

Peopleware

peopleware_m.jpgJ’ai enfin lu ce grand classique, ce n’est pas un hazard si sur Amazon PeopleWare est vendu avec The mythical man-month. Les deux sont des lectures impératives pour les chefs de projets et le management en général.

Quelques extraits des passages qui ont le plus retenu mon attention.

“When you automate a previously all-human system, it becomes entirely deterministic. The new system is capable of making only those responses planned explicitly by the builders.”

Pour moi ça résume bien l’un des principaux problèmes de la relation MOA/MOE. La MOA exprime le besoin des utilisateurs, qui fonctionnent de manière non déterministe, tout n’est pas prévu à l’avance, il y a beaucoup d’implicite. La MOE doit traduire ce besoin en programme informatique, un monde exclusivement déterministe, où l’implicite n’existe pas, tout doit y être explicite.
A propos de CMM (l’ancêtre de CMMI)

“The projects most worth doing are the ones that will move you DOWN one full level on your process scale.”

“Process isn’t worth a rip unless it’s applied to projects that are worth doing”

Je n’ais jamais été très convaincu par l’approche CMMI, maintenant je sais pourquoi.scrumandxpfromthetrenches.jpg

Dans la foulé de Peopleware j’ai lu Scrum and XP from the Trenches un retour d’expérience de Henrik Kniberg sur les méthodes agiles. En le lisant j’ai tout simplement eu le sentiment que Scrum était l’implémentation des théories exposées dans Peopleware. Si vous ne devez lire qu’un seul document cette année, c’est celui-ci.

Les ventes de livres O’Reilly

Une manière de suivre les “tendances” dans le monde des technologies et de se rendre dans une librairie et de mesurer la taille des rayons ou de compter le nombre de livres dédié à telle où telle techno.

Je vous l’accorde, la méthode est un peu rustique et peu fiable. Mais quand c’est Tim O’Reilly, l’éditeur, qui se livre à ce petit jeu en utilisant les chiffres des principaux point de ventes aux USA, ça devient très intéressant.

A lire State of the Computer Book Market, Part 1 pour découvrir la méthode, et part 2 pour rentrer dans les détails.

Par exemple sur le graphique languages de programmation: évolution des ventes de livres O’Reilly aux USA entre les premiers trimestres 2005 et 2006 on trouve:

java -6%

C# +68%

Ruby +733%

Note: en volume java reste 1ere devant C#, Ruby reste loin derrière.
Je vais donc poursuivre ma lecture de ce bouquin sur Ruby… La Ruby On Rails mania m’a contaminé 😉 On en reparle dans un autre billet.

Java, Php et Ruby sont dans un bateau…

Après son best seller “Better, Faster, Lighter Java” (il est dans la liste) Bruce Tate fait beaucoup parler de lui. Son interview déchaîne les passions sur theserverside.

En tout cas cette interview contient pas mal de remarques qui m’ont paru très pertinentes et synthétiques.

The problem Java grew up around solving was slapping a web UI around legacy stuff, mostly relational databases.

Si j’y réfléchi deux secondes c’est effectivement ce que je fais depuis que je travaille. Il poursuit en expliquant que java a résolu le problème d’une manière “slow & clean” alors que d’autre langage le font d’une manière “quick & dirty”, je pense à php, Tim Bray aussi.

Avec Ruby On Rails Bruce Tate pense avoir trouvé une manière “quick & clean” le meilleur des deux mondes. La preuve? Un projet java non fini au bout de 4 mois a été bouclé en une grosse semaine avec ROR. J’ai fait passer le “10 minutes test” à ROR. Les 10 minutes se sont transformée en 2 heures mais j’ai effectivement pu réaliser une appli toute bête avec un formulaire CRUD. Et l’appli et effectivement clean quelqu’un qui connaît ROR n’aura aucune difficulté à comprendre ce qu’elle fait et à la maintenir.

Ca ne veut pas dire que ROR est une solution miracle, sur certain point la plateforme java reste incomparablement meilleure. Il donne les exemples des problèmes de two-phase commit et d’intégration avec beaucoup de système legacy.

Il met ensuite le doigt sur une des faiblesses de java:

Java doesn’t express data very well. While Java can declare structures that hold data, it doesn’t express the data itself well. And, that’s a big reason we’re seeing a lot of XML being bolted on to Java frameworks

Et effectivement je code de plus en plus en xml… Mais depuis quand xml est-il un langage de programmation?? Est-ce que les annotations sont la réponse à ce problème?

Enfin il traite du problème du “design by committee

Sometimes, the JCP seems to say ‘Find a problem. Build the standard. And, lastly, gather the experience.’ To me, that’s wrong.

C’est ce qui conduit a des specs comme EJB 1 et 2, WS-*… A l’opposé l’approche qui consiste à implémenter en premier puis à spécifier ce marche a produit par exemple Spring et Hibernate (ATTENTION on parle du processus pour créer un standard pas un application métier). C’est aussi l’approche que recommande l’IETF pour la définition des standards qui font tourner l’Internet, ça leur a plutôt réussi, non?

Les livres que tout dévelopeur java devrait avoir lu

Joli travail collaboratif de la communauté javalloby pour nous sortir la liste des ouvrages indispensables pour les développeurs java (mais beaucoup de ces ouvrages intéresseront les développeurs en général)
Je ne peux qu’approuver cette liste de lecture, 6 des 10 premiers titres étant dans ma bibliothèque 😉 Ca me rappel ce book to read

Faites un test, si vous etes dans une société qui fait du java, faites la liste des livres qui trainent et comparez la avec celle-ci…

Le mythe du mois homme

themythicalmanmonth.jpgJe viens enfin de lire ce grand classique du génie logiciel. J’allais vous faire une petite fiche de lecture mais je m’aperçois qu’une grande partie de ce que j’aurais pu écrire est déjà dans wikipédia: lisez donc le mythe du mois homme sur wikipédia.

Un petit rappel quand même, la loi de Brooks:

Ajouter des ressources humaines à un projet en retard sur les prévisions ne fait qu’accentuer ce retard

Cette loi qui peut sembler contre intuitive est parfaitement exacte et ce livre l’a démontré et expliqué très clairement il y a plus de 30 ans. Alors pourquoi autant de gros projets continuent ils à se planter pour les raisons qui sont décrites dans cet ouvrage et dans d’autres? Alors si vous êtes chef de projet pitié lisez cet ouvrage! Les petits gars en dessous ils en ont marre de ramer parce que l’organisation n’est pas à la hauteur. Une des expressions favorite dans le milieu du développement informatique est sans doute: “ne pas réinventer la roue” et si on essayait aussi d’arrêter de reproduire les bugs notamment dans le domaine de l’organisation?

La version du mythical month que j’ai entre les mains est celle du 20eme anniversaire, elle a été mise à jour il y 10 ans… Dans ces nouvelles pages on trouve un pointeur vers PeopleWare: Productive Projects and Teams. Je ne l’ais pas lu mais il est sur la reading list. Ce livre développe l’idée selon laquelle le plus gros problème du génie logiciel n’est pas technique mais sociologique +1. On y trouve aussi des recommandations pleines de bon sens:

Le rôle du manager n’est pas de faire travailler son équipe, mais de faire en sorte qu’il soit possible à son équipe de travailler.

J’ai toujours appliqué ce principe quand j’étais chef de projet et ça m’a plutôt réussi.

Update 12/05/06:

Si un jour vous vous retrouvez face à un manager qui ne veut pas comprendre qu’ajouter des ressources à un projet en retard est contre productif, utilisez la technique du big book: Dites lui qu’il est très urgent qu’il lise le “mythe du mois homme” et offrez lui plusieurs copies de l’ouvrage en lui disant  que c’est pour qu’il puisse le lire plus vite.