A great talk on Coffee and Software development by Linda Rising was posted on InfoQ. Watch it now!

Quand je suis allé en vacances à Cuba, j’ai choisi un livre qui sortait un peu de mes lectures “sérieuses” mais pas trop. Ma mère avait vu un entretien à la télé avec Daniel Tammet, écrivain autiste génial, et m’avait incité à en apprendre davantage – c’est à dire à lire le livre dont il faisait la promotion.

Dans ce livre, il raconte que s’il est capable de réciter les 22000 premières décimales de Pi, il est en revanche souvent incapable de reconnaître le visage de ses amis. D’un côté il est capable de réaliser ce qui paraît à la grande majorité d’entre nous tout simplement incroyable ; de l’autre, il est incapable d’accomplir une tâche qui nous paraît tellement banale que nous ne réalisons même pas que c’est est une ! L’explication qu’il donne à ce phénomène est une “attention” et une “obsession” différente – dans son cas, il a une obsession pour les chiffres, auxquels il attribue une couleur et une taille. La faculté de reconnaître un visage, quant à elle, recourt à une capacité de synthèse – faire abstraction des détails pour voir le tout – qui lui manque.

Plus loin dans ce même livre, – et c’est là que nous arrivons au titre de cet article – il a un chapitre un peu fourre-tout (“Food for Thought”) dans lequel il étale ses réflexions sur divers sujets de société et d’actualité. Si les premiers chapitres m’ont donné des coïts intellectuels multiples, celui-ci, en revanche, m’a laissé un peu … coi. Partant de bons sentiments (un cri du coeur pour combattre l’illétrisme, mais surtout ce que j’appelerais l’”inchiffrisme”), il y dénigre wikipedia et les lotteries, machines à sous et autres jeux de hasard.

Il y démontre que les gens seront statistiquement toujours perdants à tenter leur chance à ces jeux. Il ne lui vient par contre même pas à l’esprit que des gens pourraient jouer, non pour gagner, mais pour éprouver certaines sensations et émotions. Je ne veux certainement pas défendre les joueurs – je n’ai moi-même jamais joué et trouve effectivement cela stupide – mais je comprends pourquoi certains de mes amis le font. Il renforce par contre efficacement son argument qu’il n’arrive pas à “voir le tout”.

Pour en venir au coeur du sujet. J’ai souvent observé des projets initiés comme on joue aux machines à sous. On met de l’argent, on tire sur la manette, on regarde les lumières s’animer et les figures défiler, puis on crie de joie si on a gagné. Sinon … on recommence. L’autre jour, je regardais jouer un ami dans un bar. Il gagnait 17$ pour une mise de 2$. Je le voyais alors avec horreur rejouer immédiatement, et jouer encore jusqu’à ce qu’il ait tout perdu.

Mon horreur venait bien sûr de nos perceptions différentes. Pour moi, avoir une mise de 2$ dans la machine était comme un accident : “Mon dieu, 2$ sont tombés de ma poche dans cette machine !” S’il en sort 17$, je trouve cela merveilleux ; je transforme cet accident en opportunité et je récupère ma mise, plus 15$ ! Pour lui, par contre, un gain inférieur à 30 ou 40$ ne justifie pas l’arrêt du jeu. En fait, soyons honnêtes, je ne peux pas vraiment expliquer ce qui se passe dans sa tête parce que je ne le comprends pas vraiment. Le fait est qu’on n’apprend rien de ce genre de jeu. On a autant de chance de gagner la première fois que la seconde, etc … Il y a autant de raison de s’arrêter après avoir gagné 15$ que la fois d’après, et ainsi de suite.

Il m’a semblé que beaucoup de grandes organisations traitent leurs projets comme des machines à sous. C’est à chaque fois un jeu de hasard.

La différence, cependant, c’est que pour les projets, on peut améliorer progressivement ses chances de succès. Pas avec les machines à sous.

Le PMBOK conseille de documenter et d’utiliser les leçons apprises, Agile s’appuie sur des équipes stables et des rétrospectives, Lean met l’accent sur l’amélioration continue des processus. Cependant, les organisations qui utilisent vraiment ces mécanismes de façon conséquente sont bien rares. Je vous invite à faire part de vos expériences qui démontrent le contraire – ou non.

Peut-être est-ce le temps de comprendre ce qui différencie les machines à sous des projets et programmes.

Here’s a little app that I wrote one year ago while studying the latest javascript best practices… It allows you to pick The Best Web Framework for your needs. But it does so from a psychological theory called the name-letter effect. After years and years of research and practice, this is the method I have used with the best success (for my ego).

Other methods of choosing a web framework include:

1. Deciding which framework to choose and then coming up with reasons that you can provide managers,
2. Deciding which framework to choose and then going through the list of strategies, picking the one whose result is the chosen framework,
3. Asking your arch nemesis which framework s/he recommends and pick the main competing framework,
4. Hiring an architect and ask him to find reasons to recommend the framework you have chosen, fire him/her if s/he does not comply,
5. Looking at meta characteristics of frameworks and do a production-ready prototype (more on this in another, more serious, post)

Now, here’s your action item. You probably had to choose a web framework in your career as a senior developer/architect. What was it? Can you explain your choice using the name-letter effect theory? If so, I would love to hear about it! Don’t be ashamed- you didn’t know

There are two kinds of architects. Solution Architects and Problem Architects. The former define solutions while the latter define the problems to address. Since Problem Architect is not a title that people can carry with pride, they are called Managers instead.

Well. I love open source software when it’s mature, so it was just weird that I had my blog on Blogger. Especially since -to say the least- I have not been impressed with Blogger’s downtimes and numerous blunders. It definitely shows that it was acquired and not home-grown. It’s also an opportunity for me to try out a new way of mixing a blog and pages in the same site, which will come in handy when I launch my new site. Stay tuned.

Excellent read, this article on “the get-small movement”. Here’s an excerpt:

“How much energy and creativity might be unlocked if all the members of an organization felt in control?” he writes.

By making sure products in development meet customer needs each step of the way, Avocent has been able to avoid spending weeks correcting errors in the final product, says Ben Grimes, chief technology officer.

Very interesting read: http://www.infoq.com/news/2008/07/agile_failures

U.K. telecom giant BT Group adopted agile programming in 2005 and found that after some initial speed bumps, the development philosophy is a boon to its business

By Thomas Hoffman, Computerworld
March 11, 2008

Don’t Repeat Yourself. I repeat. Don’t Repeat Yourself.

An introduction to the Agile Scrum “methodology” is presented in this talk by Kent Schwaber (Google Techtalks, Sept. 2006). He speaks for close to one hour from memory, resulting in a somewhat sketchy but nevertheless thought-provoking talk. This is also a strong testimony in favor of refactoring legacy code… If you are interested in understanding more about when or why to refactor code, or are simply looking to be inspired by the lively description of an Agile methodology, watch this now!