Thursday, August 21, 2008

Di. 19 Aug. - Dazzle [Siouxsie]

(suite d'hier... Lire d'abord le post d'en-dessous)
Dans mon monde de maintenant, les choses sont très différentes. D'abord, il n'y a pas vraiment de problème à résoudre. Les problèmes, on serait même plutôt du genre à se les créer, comme ça, rien que pour rire. Par ailleurs, l'argent tombe du ciel ou d'on se sait pas trop où, mais il n'y a pas de lien direct entre ce qu'on fabrique et un revenu monétaire. Mais par contre, comme partout ailleurs, il faut bien un mécanisme pour valoriser les employés, sinon ils se lassent et passent chez Facebook (pas grave, d'abord, on les rachète quand on veut!). Et donc ici l'étalon de mesure de la performance est la complexité de la solution:
- "code simple = ..." (incrédule:) qui veut perdre son temps à faire des machins simples?
- "code complexe qu'une chatte n'y retrouve pas ses rejetons = gros bonus."

Vu de l'extérieur, on n'y croit pas à mon histoire: regardez la home page de Google, difficile de faire plus simple, non? Eh bien justement, c'est un grand principe méconnu de l'informatique: un système simple à utiliser est complexe à construire et vice-versa. Si on en était resté aux systèmes simples, on serait encore tous avec MS-DOS (et une grande proportion des utilisateurs payent d'ailleurs encore quotidiennement le prix des systèmes construits à la va-vite).

Et donc ici, le "pourquoi faire simple quand on peut faire compliqué?" règne en maître. Mais attention: il y a des règles, c'est pas si simple de faire pas simple!

D'abord, il y a la pratique du "code review" complet: tout ce qu'on produit est systématiquement revu par au moins un autre développeur avant d'être accepté. Et comme lui, il n'a aucun intérêt à ce que ton code soit complexe, il va essayer de s'arranger pour te le simplifier, ton code, bardaf!

Du coup, il faut ruser: pour faire un code complexe, il faut complexifier aussi le produit. Ca tombe assez bien, il existe des tas de ruses pour complexifier un produit, il suffit de glâner les derniers acronymes à la mode: ton produit, il doit être compatible Web2.0, mobile, GPS, GPRS, CRM, collaboratif, interopérable et avoir une dimension de réseau social. Et voilààà, le tour est joué!

Et là, on retrouve la force de la grande entreprise: il y a ici aussi des managers qui ont toujours une pelletée d'acronymes prêts-à-l'emploi sur eux (enfin, sur leur blackberry): en deux réunions, t'as fait le plein d'acronymes et c'est bon, ça devrait avoir monté le niveau de complexité de ton projet de calculette online à un niveau qu'il va te falloir cinq mois pour la construire. Là, on voit que ça a l'air plutôt bien embarqué, pour le bonus.

Mais c'est sans compter les régiments d'autres développeurs planqués dans les autres centres de Google, qui œuvrent sans honte à contrecarrer tes plans: ces ignobles sont justement déjà sur un projet de calculette Web2.0, ou de bloc-note GPS/CRM, ou de bidule GPRS/social, enfin, tous des machins qui font que ce serait tout de même vachement plus simple (aaaaaarggghh!) d'aller ajouter ta petite brique à leur édifice plutôt que le faire de ton côté, que tu vas pas réinventer la roue, non?

Et c'est là qu'il faut déployer une savante maîtrise de champion de course d'obstacles pour arriver à les esquiver les uns après les autres, redéfinir le projet et recombiner les acronymes (voire en laisser tomber: «Haha! non, justement, le but de mon projet c'est un peu comme le bloc-notes social, mais sans GPS, c'est subtil mais ça change tout!»)

Ou alors, foncer dans le tas, produire une montagne de code à la vitesse du guépard, en espérant qu'un maximum passera les tirs de barrage des divers comités de "review".

Mo. 18 Aug. - A&E [Goldfrapp]

J'ai noté récemment une différence fondamentale entre mon job d'avant et mon job de maintenant, qui fait que je fais moins d'efforts pour être ailleurs qu'à mon écran.

Dans mon monde d'avant, celui de la consultance, on est payés pour résoudre des problèmes qui existent. Enfin "on est payés", entendons-nous: La boite de consultance est payée, et en retour, elle "valorise" ses employés, c'est-à-dire trouve mille et un trucs (certificats de "Jo a super bien fait son travail", "Marie la super-employée du mois", tournée générale de boites de choco-promo parce que le projet a bien tourné, etc. etc.) pour justement ne pas avoir à les payer, eux... Et donc:
- "petit problème = petits sous", et
- "gros problèmes = jackpot",
ce qui se propage aussi tout le long de l'échelle et au niveau du consultant aussi,
"petit problème = heineken", et
"gros problèmes = champagne".

Et donc logiquement l'humain s'adapte et la logique du consultant se déploye en deux temps:
1) «Eh boss, tu le vois là mon problème qu'il est gros, ooh oui, ouh là là, qu'il est gros!»
2) «Et voilà, j'ai résolu mon gros problème, waouh, c'était ardu parce que le problème il était bien gros! (Ah, gros qu'il était ça oui!) (wink wink et mon bonus aussi il va être gros et gras)»

Premier temps, il faut s'assurer que tout le monde surévalue bien l'ampleur du problème, puisqu'elle est directement proportionnelle au niveau du bonus en fin de course. En général, ça ne demande pas de talent particulier puisque les managers en tous genres n'ont pas la moindre idée de la nature du problème, gros ou petit, ils sont plutôt crédules et fonctionnent dans la même logique, donc très ouverts à avoir des problèmes de la catégorie "gros". Ca demande par contre pas mal de palabres, se renseigner à gauche à droite, faire présence dans des tas de réunions et répéter son petit speech à tour de bras. Pas d'être assis à son écran, si ce n'est pour envoyer des mails. Dans cette phase-ci, je pense qu'il est même honnête de dire que toute heure passée au clavier à bosser sur une solution au problème est doublement perdue: ça ne fait pas de publicité, et ça résoud, et donc rétrécit, le problème.

Deuxième temps, si tout s'est bien passé, on a amplement le temps de réaliser ce qui doit l'être, puisqu'on a sur-budgété le truc d'au moins 400%. Donc on résoud le problème en pensant au champagne et aux vacances aux Caraïbes payées par le bonus.

Le cauchemar des consultants: les braves couillons qui traînent dans le bureau du boss au moment inopportun et qui lâchent: "Ah mais ça c'est hyper simple, je vous le fais pour demain si vous voulez". Malheureusement, ils sont assez nombreux, ceux-là qui ont rien compris du tout et qui se contentent d'un paquet de chips là où on pouvait aller chercher la bouteille de champagne et le foie gras!

La stratégie perdante: Gonfler le problème et se faire damer le pion par l'autre enflé de l'équipe d'à-côté qui a une prétendue meilleure solution au problème parce qu'il avait justement prévu le coup alors qu'il travaillait sur son (presque le même) problème à lui (ce qui est en général complètement faux, mais il en profite pour doubler son potentiel de bonus, le salaud!)

(la suite demain)

Friday, August 1, 2008

Fr. 1 Aug. - Talk Radio [Dandy Warhols]

Aujourd'hui c'est la fête nationale ici. Et donc, comme chez nous, pour respecter la tradition, il pleut.
La Suisse est un pays de traditions. Par exemple, le dimanche c'est jour de repos et on rigole pas avec ça: tous les magasins sont fermés, et on est priés de pas faire de bruit dans la ville pour pas déranger les familles qui prennent la tarte chez mémé. Du genre, on n'est pas censés faire sa lessive (dans ma maison, il y a une machine à laver pour 8 appartements et une tournante de jours pour l'utiliser -- tournante qui ne comprend pas les dimanches parce que, à en croire un avis collé sur la machine, "it's just rude": c'est impoli!).
A l'inverse, aujourd'hui tout au long de la journée, tout le monde joue avec des pétards. A chaque coin de rue, il y a des gamins qui font un potin pas possible, pour peu on se croirait à Baghdad.

La semaine prochaine, c'est la street parade, un défilé de musique techno pendant tout le week-end, ça promet d'être folklorique aussi tiens...