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".