Quand j’ai vu tourner cette image sur Twitter ce week end, cela m’a fait gentiment sourire car c’est un peu le sentiment que j’ai eu lorsque j’ai effectué mon tout premier stage à la DSI de Louis Vuitton à la fin de mes études.
Quelle ne fut pas ma déception lorsque derrière le strass et les paillettes il y avait en fin de compte un bonne majorité de vieux programmes d’une dizaine d’années faisant tenir la boite et nécessitant des experts vieux de la vieille pour maintenir ces pachydermes ancestraux en bon état de fonctionnement. Idem pour mon amie qui se retrouve au département technique d’un grand groupe français de paris en ligne et qui désespère de voir du code mort ou du code répété joncher les lignes de la solution en très forte proportion..
C’est là où je veux en venir justement. Des exemples comme ceux-ci je suis persuadé qu’il y en a des millions. Dans les grosses boites du CAC, même chez Google, Facebook ou dans toute startup à la mode. Et c’est qu’il y a une raison, qu’on ne saisit pas à la sortie de l’école, des étoiles plein les yeux songeant que l’on va travailler au quotidien sur un chef-d’oeuvre de code: le code que vous produisez ou que les équipes produisent pour votre solution doit avant tout être fonctionnel et servir votre business.
Ne me faites pas dire ce que je n’ai pas dit par contre: il ne faut pas coder avec les pieds et sans méthode. Il faut penser au quotidien à la “réusabilité” du code (DRY, Abstraction), produire du code clair pour se relire ou pour être relu par ses partenaires de projet (KISS). Mais il faut avant tout être capable de jauger la dose d’art à placer dans son code en fonction du temps disponible et des impératifs business de votre boite. A trop vouloir faire parfaitement, à prévoir une scalabilité inutile et prématurée vous exploserez indéfiniment tous vos délais et passerez à côté de belles opportunités: lancer rapidement sur le marché un produit simple et fonctionnel, récolter les précieux feedbacks de vos utilisateurs, ne pas vous enfermer dans un développement long et rester agile pour pivoter si besoin.
Pour résumer: faire au mieux dans le code pour servir votre business, avancer vite mais proprement. Vous construisez une cathédrale, mais vous vous occupez des fondations tout d’abord, des murs en pierre brute. Une fois la première pièce achevée, laissez entrer vos visiteurs, et commencer en parallèle de la construction d’autre pièces à refactoriser votre code régulièrement, rapidement pour vous approcher de votre oeuvre d’art. Polissez vos pierres brutes, ajouter des gargouilles, des vitraux.. Mais n’oubliez pas qu’avant tout, c’est le fait d’accueillir rapidement vos premiers fidèles et de faire la quête auprès d’eux qui vous permettra de finir les fioritures, et rarement l’inverse..
D’accord avec l’idée générale (inutile de perdre un temps précieux en finitions) mais pas avec l’analogie de la cathédrale. Une cathédrale se construit par couches, impossible de changer les fondations quand on travaille sur les flèches. Si on n’a pas construit assez solide en bas, tout s’écroule.
Je préfère construire des datacenters en containers (http://is.gd/RLMf8t pour la référence) : des blocs grossiers avec des interfaces bien définies qu’on peut assembler de manière modulable pour tester des choses. Si un bloc faiblit on le remplace par un autre plus solide.
La qualité du code doit dépendre de la criticité du bloc quand même. N’allez pas prendre le risque de perdre des données client au nom de l’”agilité”. Pareil si vous écrivez du code installé chez le client, c’est plus dur à patcher. Mais pour du code non-critique côté serveur, ma politique serait presque : “ça a l’air de marcher, ça passe quelques tests de base, mettons-le en prod”, et ensuite on affine.
+1
En effet Pierre, je pense aussi qu’il est important de bien réfléchir conception et interface, notamment dans une optique Component Driven Development (CDD) de boites noires. Sinon, c’est vrai, c’est un chateau de cartes qui risque littéralement de s’écrouler!
Par contre en effet, tant que cela fonctionne, que les tests passent et que cela tient une charge raisonnable, go prod. Toujours à temps ensuite de refacto / scaler comme il se doit, ou adapter en fonction des retours :)
Merci pour tes commentaires qui sont toujours intéressants et bienvenus! ;)
Je te retourne le compliment, j’adore ton blog. On entend trop rarement l’équipe technique des startups s’exprimer en France.
Justement si on applique Scrum et/ou travail par bloc (comme l’exemple de Pierre), ça veut dire:
ne pas bâtir des cathédrales mais coder des oeuvres d’art.
C’est vraiment l’inverse, une cathédrale est une somme monstre de calcul, dés le départ il faut calculer l’emplacement de chaque élément car c’est un jeu de force mécanique qui maintient l’ensemble. Par exemple à Notre Dame, l’architecte de départ à fait des erreurs de calcul et il a fallu ajouter des arc-boutants (qui empêchent les murs de partir vers l’extérieur).
Autre exemple, l’espace entre les colonnes définit la hauteur maximale de la cathédrale.
En peinture c’est totalement différent, toutes les peintures sont la superposition de couches. Certes il faut penser au début où on veut aller mais avec une marge de manoeuvre assez large, par exemple modifier l’emplacement d’une main ou réduire la taille d’une lance. On ne le remarque que dernièrement grâce à l’analyse des oeuvres avec des outils scientifiques, sur certaines peintures c’est carrément des personnages qui ont été effacés !!
La méthode de travail est assez malléable aussi: Rembrandt, pour la Ronde de nuit, avait fait des portraits des personnes seules sur des toiles à taille humaine, ensuite il les reproduisait sur la toile finale.
Je ne parle même pas des travail préparatoires, où sur une toile le peintre va faire 10, 20 voir 30 mains, pour trouver la main parfaite qu’il reproduira sur l’oeuvre.
Ps: je code avec le concept de travail préparatoire, un projet test où je ne fais qu’une seule action qui est ensuite recopier dans le vrai projet.
Hum, je dois dire que tu viens de bien malmener mon analogie oeuvre d’art / cathédrale là.. :)
Le souci de l’oeuvre d’art, c’est que même si tu peux ajuster via les différentes couches, ton n’oeuvre ne sera jamais exposée tant que inachevée.. J’imaginais plutôt Notre Dame en effet (oui oui, je suis passé devant ce week end) où grosso modo tu définis l’emplacement au sol, la hauteur, la structure générale, puis t’attaques aux fondations. Puis étage par étage. Les fidèles ont commencé à se recueillir alors que la coeur et les deux tours n’étaient pas terminées: tu releases un MVP exploitable de ta solution rapidement. Tu te rends compte qu’il faut des contreforts (de toutes façons, c’est plus joli ainsi je trouve :)), on peut imaginer que c’est un premier retour user, avec des tests de montée en charge, chose ignoré/mal conçu initialement qu’il faut rapidement adapter. Puis viennent les dorures, les vitraux, les enluminures, les cierges, les curés toussa toussa.
Je reste donc intimement persuadé que l’oeuvre d’art, tu la sors one-shot et tu ne la touches pas (on aurait fait sourire la Joconde depuis longtemps sinon) tandis que ta cathédrale (ou une tour d’entreprise à la Défense par exemple) tu suis plus le cheminement que j’ai essayé d’expliquer ci-dessus.
Je ne connais pas par contre ce concept de “travail préparatoire”. Peux-tu m’en dire plus?
> Le souci de l’oeuvre d’art, c’est que même si tu peux ajuster via les différentes couches, ton oeuvre ne sera jamais exposée tant que inachevée.
C’est un peu la différence que je fais entre Lean et Agile : le but du premier est d’exposer le produit au monde réel le plus vite possible, alors que le second se contente d’itérations en interne.
Vu l’employeur de Sylvain (à moins qu’il ait changé depuis) ça m’étonnerait que son but soit de mettre en production le plus vite possible.
Ceci dit je veux bien des infos sur le concept de “travail préparatoire” aussi. J’aime bien les prototypes jetables (j’écrirais quelque chose là-dessus un jour…) mais ça n’a pas l’air d’être exactement ça.
C’est vrai qu’un tableau n’est livré qu’une fois achevé, alors qu’on peut utiliser une cathédrale avant la fin de sa construction… en même temps, la construction d’une cathédrale durait plusieurs décennies (à peu près de 200ans pour Notre Dame XD … ).
La comparaison de Pierre entre la peinture et les méthodes Agiles est très juste, on boucle sur des itérations en interne mais on livre qu’une fois l’oeuvre terminée.
Pour le travail préparatoire (aussi appelé étude):
http://www.culture.gouv.fr/documentation/joconde/fr/decouvrir/expositions/Main/expo_main_oeuvre.htm
Un travail préparatoire consiste à faire un élément isolé (ex: une main), avec plus ou moins de complexité, pour voir lequel est le “meilleur”. Certaines fois, le travail (ou étude) est juste réalisé pour s’entrainer, aucun objectif à court terme, par contre 10ans plus tard le peintre ressort son étude pour la répliquer sur un tableau.
Pour la prog, je le fais sur des choses très limitées, les deux dernières fois étaient télécharger un fichier puis le copier dans le cache de la carte SD sous Android, et parser un fichier xml sous Android. Dans les deux cas, je finis avec une fonction/méthode que je copie/colle dans le vrai programme.
ça s’intègre très bien avec le Lean car toute (ou presque) action se trouve dans une fonction/méthode isolée. L’inconvénient est qu’on ne sait pas trop dans quelle classe copier/coller les fonctions, je me retrouve avec des classes un peu bizarre qui font un peu n’importe quoi (ex: FileManager = la classe pour faire des trucs avec des fichiers XD ).
A l’arrivée, on a un pack de librairies, en PHP c’est puissant car on réutilise beaucoup, en Java ça demande une bonne réflexion pour ne pas finir avec 40 classes statiques…
Ps: désolé, je ne voulais pas mettre à mal l’analogie avec les cathédrales et la peinture ;) . Moi même j’ai beaucoup de mal à expliquer le Lean (ou continuous development) et je n’ai pas d’analogie claire -_-