T'es pas game...

T'es pas game de te mettre un bas de nylon sur la tête, d'entrer dans une banque et de faire un retrait. T'es pas game d'invoquer ta liberté de religion si l'on exige que tu retires le dit bas de nylon.

Fast, Cheap, Good - Choose any two

J'avais lu cette phrase dans un livre de Craig Larman a l'université. Elle peut etre interprétée comme suit : dans un projet de développement, étant donnée les ressources limités, il faut continuellement choisir de négliger (de sacrifier) un aspect du développement : le cout, la qualité ou le temps de livraison. J'ai retrouvé une équivalence moins élégante mais certainement plus vraie concernant les sliders avec lesquels peut jouer le gestionnaire de projet : le cout, la qualité, le temps et le nombre de fonctions. C'est ce que j'ai appris en travaillant avec Scrum. On peut confronter le client et lui demander de choisir quelles sont les fonctions dont on peut se passer.

Les langages spécialisés ou "niche languages"

Réflection intéressante inspirée de la lecture de mon dernier livre, Brooks parle de la tendance à la création de "niche languages", des languages voyant le jours pour la résolution de problèmes spécifiques. Celui-ci met en opposition les langages "tout-usage" classiques tels que C++ ou Ada à des langages plus spécialisés. Je ne peux pas m'empêcher de faire le lien avec la "nouvelle" passion, pas si nouvelle que ça, de Martin Fowler pour les langages spécialisés. Je fais également le lien avec le langage F#, un langage fonctionnel qui me rappelle que d'autres paradigmes existent pour solutionner des problèmes. Je dois approndir le sujet.

The mythical man-month

J'ai terminé la lecture de ce classique de la gestion de projets informatiques. Il est étonnant de constater jusqu'à quel point les problèmes essentiels du développement logiciel sont restés, à peu de choses près, les mêmes, depuis les tous débuts. Ce qu'il faut retenir : en développement logiciel, on n'augmente pas la productivité selon un ratio 1:1 en ajoutant un programmeur au projet. En particulier pour les gros projets. La manière la plus optimale de développer est une petite équipe. La petite équipe la plus efficace est la paire. Malheureusement, la plupart des gros projets logiciels sont trop grand et prendraient trop de temps à être réalisés par une si petite équipe. C'est pourquoi, pour bien planifier les plus gros projets informatiques, il faut tenir compte du facteur de la communication. L'auteur mentionne également que pour un maximum de cohérence et d'uniformité, (celui-ci appelle ça l'intégrité conceptuelle), il faut qu'une personne, un architecte ait une vision globale du projet, et possiblement plusieurs sous-architectes, coordonnés par un architecte-chef pour les plus gros projets. Un dernier point intéressant amené par l'auteur : la maintenance. Selon lui, toute réparation tend a détruire la structure et de ce fait, augmente l'entropie et le désordre du systeme. Meme les réparations les plus habiles ne font que retarder l'inévitable chute du logiciel dans un chaos irréparable, a partir duquel, il faut reconcevoir depuis le début. (traduction adlib).

En conclusion, ce livre est une sorte d'essai, réfléchissant et faisant le point sur la profession. Il m'a éclairé et montré une perspective très intéressante qui est, je crois, incontournable lorsqu'on s'intéresse au génie logiciel en 2011.

De la complexité des logiciels

Dans son livre "The mythical man-month", Brooks attaque le problème de gérer le développement de systèmes de grande taille. On y trouve une citation incroyable qui m'a frappée par sa vérité :

In my experience most of the complexities which are encountered in systems work are symptoms of organizational malfunctions. Trying to model this reality with equally complex programs is actually to conserve the mess instead of solving the problems.

Fascinant ! Probablement qu'un partie de la complexité que je rencontre dans mon travail vient d'une lacune de programmation de l'équipe mais il y a surement une partie qui pourrait être attribuable à un processus d'affaire mal optimisé.

Code kata

How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes from practicing; applying the theory over and over again, using feedback to get better every time.

How do you get to be an All-Star sports person? Obviously fitness and talent help. But the great athletes spend hours and hours every day, practicing.

But in the software industry we take developers trained in the theory and throw them straight in to the deep-end, working on a project. It’s like taking a group of fit kids and telling them that they have four quarters to beat the Redskins (hey, we manage by objectives, right?). In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions. source

Je trouve l'idée de faire des "code kata" absolument géniale. Seulement, ça prend beaucoup de motivation pour se perfectionner en dehors des heures de travail.

Combien ça coûte mourir ?

Sujet que personne n'aime vraiment aborder. Je regardais le prix des cercueils : on parle d'environ 1500$ pour un cercueil en bois; les prix varient beaucoup. Une urne : entre 150 et 200$. J'ai également trouvé en France une entreprise qui vend des cercueils en carton : beaucoup plus léger et moins cher (entre 100 et 600 euros).

Question du jour. Tout le monde sait que l'industrie funéraire ira probablement bien dans les prochaines années à cause de la courbe démographique que l'on connait. Étrangement, un peu comme pour l'industrie du mariage, les prix semblent uniformément et artificiellement gonflés. Imaginons que de nouveaux joueurs entraient dans ce marché et faisaient baisser les prix, croyez-vous que cela se passerait sans représailles ?