This post is available in english on my personal blog.
Je rentre juste de trois jours aux QCon de Londres. C’est comme toujours un grand moment permettant une véritable prise de recul. Je peux respirer, ouvrir les yeux sur ce que font les autres et comment ils travaillent, sentir quelles sont les tendances et surtout, tenter d’appréhender ce que sera mon job dans un an, voire, plus loin.
Promis, je vous ferai, dans les jours qui viennent, une compilation des meilleurs moments de la conférence et des points les plus marquants. Mais avant tout, je voulais vous faire une réaction à chaud sur quelque chose qui me semble important.
Je reviens aujourd’hui avec un goût désagréable dans la bouche (non ce n’était pas la bière qui était, comme toujours, excellente). Un goût amer et un peu de colère aussi.
En deux mots : la modélisation n’est plus simplement absente (comme c’était pratiquement le cas lors des deux dernières éditions), c’est devenu un gros mot.
Que le code soit à l’honneur, c’est bien naturel dans une conférence consacrée au développement. Que l’on fustige les erreurs commises par le passé (en particulier la “sur modélisation” symptomatique d’un déficit de confiance dans les processus de développement) me semble aussi plutôt sain.
Mais que l’on entende des sentences définitives du genre “comme chacun le sait, les modèles ne servent absolument à rien” dans la bouche de stars comme Robert C. Martin, alias Uncle Bob (qui a pourtant écrit en 2003 un remarqué “UML for Java Programmers” !), qu’un Dan North (par ailleurs excellent, je vous en reparlerai) considère l’usage d’un modeleur comme une inutile “complification”, relève de l’hypocrisie, de la démagogie ou de l’intégrisme (voire de la simple bêtise, indissociable du dernier).
La seule conférence à laquelle j’ai assisté qui faisait encore la part belle aux modèles était celle d’Eric Evans qui parlait de conception agile. Encore avait-il rayé le mot Modèle du titre, pour celui de Design plus consensuel. C’est lui qui a, d’ailleurs, eu le mot juste : en abandonnant la modélisation, la communauté du développement a, un peu trop rapidement “jeté le bébé avec l’eau du bain” (sic).
En fait, j’ai eu l’impression d’être dans le domaine du religieux et d’assister à des professions de foi.
Il y a, d’un côté, les fondamentalistes du code, pure monothéistes, nostalgiques d’un âge d’or mythique où le développeur était le seul maître de sa production, en relation directe avec Dieu (le Product Owner), dépositaires d’un savoir millénaire (le Software Craftsmanship) qui se transmet de bouche de gourou à oreille de disciple.
Et il y a la secte des UMListes, vus comme de dangereux illuminés schismatiques, dont les délires auraient corrompus le monde parfait des précédents et qu’il faut exterminer par tous les moyens. J’ai eu l’impression d’être soumis à une fatwa.
Comme toujours lorsqu’il y a des problèmes, il faut trouver des boucs émissaires. Les modèles (et ceux qui les font) semblent jouer ce rôle aujourd’hui : symboles du “Big Upfront Design”, c’est eux qui portent la responsabilité des échecs des grands projets. Les modèles sont vus comme des artefacts de pure documentation : modéliser serait une activité chronophage et inutile (voire perverse), en particulier dans un monde agile.
Dans un tel environnement, impossible de sortir ma carte de visite : sous mon nom, il y a marqué “MDA business line manager”. Comme une maladie honteuse.
Pourtant, il me semble que modéliser, au contraire de développer, permet :
- d’analyser un problème,
- de compresser sa complexité,
- d’appréhender sa globalité,
- de s’abstraire de contingences techniques,
- de communiquer.
Mon cerveau n’est pas suffisant pour faire tout ça sans assistance. J’ai besoin d’UML (ou de tout autre formalisme), à la fois comme d’une béquille, d’un tableau blanc, d’une extension de mémoire et d’un formulaire de maths.
Modéliser n’est pas antagoniste de développer (sans parler de MDA qui combine les deux activités) : modéliser permet simplement de mieux développer.
Et d’ailleurs, le code EST un modèle (“système d’abstractions qui décrit des aspects sélectionnés d’un domaine”), au même titre qu’un diagramme UML. Juste un peu plus verbeux (et un peu plus facilement exécutable).
Pour conclure, il me semble que ce hiatus est, avant tout, très représentatif de modes de pensées différents : une pensée analytique “à la française” (après tout, Descartes et Merise sont des créations bien de chez nous) face à une pensée pragmatique anglo-saxonne.
J’aime à penser qu’il y a du bon dans les deux mondes et que les deux se complètent agréablement. C’est même ce qui, à mon avis, constitue l’intérêt principal de notre métier : analyser des problèmes pour informatiser leur résolution. C’est ce qui quotidiennement renouvelle ma motivation : comment faire rentrer dans un (bon) programme la complexité du monde réel.
Comme le dit Estelle Gleeson, la responsable marketing de Sparx System : « Please visit the release page below to learn more and take advantage of this major milestone release : 
Derniers commentaires