QCon, Modèles et Intégrisme

This post is available in english on my personal blog.

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

20 réflexions au sujet de « QCon, Modèles et Intégrisme »

  • 16 mars 2010 à 9 h 10 min
    Permalink

    Écrit avec passion, et une pointe de colère qu’on ressent dès les premières lignes, j’aime beaucoup l’article, et j’aurais bien aimé assisté à la conférence pour entendre et tenter de comprendre les arguments d’Uncle Bob et ses compères.

    As tu pu en débattre avec eux ? Comment ont ils présenté leurs pensées ?
    La suite !!! 🙂

  • 16 mars 2010 à 13 h 26 min
    Permalink

    Faut quand même reconnaitre que les outils associés et particulièrement ceux des grand éditeur de soft sont assez absconds. Par certains cotés ils rappelent l’artillerie lourde des serveurs d’appli J2EE à la grande époque 😉
    Il y a aurait de l’UML « Kiss » ce serait bien mieux 🙂

    Pour ma part je pense que de toute façon il y a un pb à la base au niveau du langage Java (je ne connais pas C# mais a mon avis on doit pas être loin) qui déforme tout et s’entoure d’artifices dans tous les sens pour arriver à boucher les trous.
    Il y aurait un bon langage qui pourrait se representer sous forme de code ou de modèle sans ambiguité, le problème serait résolu. 😉

    PS : « étoile jaune » t’y vas un peu fort là 😉

  • 17 mars 2010 à 13 h 29 min
    Permalink

    IMHO,
    les modèles ont posé et posent beaucoup de problèmes dès lors qu’on ne dispose pas de feed-back à leur sujet (pertinence de l’abstraction du réel qu’ils représentent, dans le contexte).

    Quelques façons de confronter le modèle au réel :
    – coder une partie du modèle et lancer l’application – cf les agilistes
    – en donner une représentation plus parlante qu’UML, avec une IHM comme le fait D.OM
    – générer l’application à partir du modèle – approche Model-Driven

    Si l’on respecte cette « règle du feed-back nécessaire », alors les modèles apportent effectivement les avantages cités dans ce billet, et leur conséquence associée : gagner du temps, substantiellement.

  • 17 mars 2010 à 21 h 55 min
    Permalink

    Quelques réflexions que m’inspire ton billet d’humeur :
    En matière d’analyse, il y a des approches top-down, des approches bottom-up et des partisans absolus de chaque approche. Ça correspond à une façon pour un esprit de fonctionner.
    Certains ont besoin de modèles pour comprendre un problème, d’autres ont besoin de l’attaquer directement par un petit bout, d’itérer, de refactorer, de tirer un bout un peu plus grand, de recommencer…

    On peut faire du RAD, de l’itératif avec des modèles, mais peu de personnes le savent. Nous faisons partie des happy few 🙂

    Je me souviens d’un projet où les modèles (fonctionnels) devaient suivre un tel formalisme qu’ils en étaient illisibles, qu’ils perdaient complètement cette force évocatrice qui peut en faire un si bel outil d’analyse. C’est peut-être l’expérience de beaucoup de ceux qui jettent aujourd’hui ce bébé avec l’eau du bain.

    Enfin, appelons ça une mode. Et, dans une mode, la force de l’adhésion à une nouvelle tendance va de paire avec la force du rejet de la précédente, qui est elle-même en rapport direct avec la façon dont on se sentait avec elle, en rapport avec son adéquation avec notre tournure d’esprit, pour en revenir au début. Et d’ailleurs, souviens-toi que ce rejet, tu l’as déjà connu 10 ans en arrière, à une échelle moindre, avec D.OM.

  • 19 mars 2010 à 17 h 24 min
    Permalink

    Enfin un article qui m’a vraiment intéressé malgré mon œil commercial. Bravo Greg 😉

  • 23 mars 2010 à 5 h 15 min
    Permalink

    @Frédéric Zgud
    Salut Fred,
    Je pense que si un (bon) modèle est illisible, il y a peu de chances que le code correspondant le soit plus.
    Un modèle est « bon » s’il n’ajoute pas de complexité accidentelle et compresse la complexité intrinsèque de ce qu’il représente.
    Tout le problème c’est de faire un bon modèle ! Ca demande un certain savoir faire. Mais faire du bon code n’est pas une tâche aisée non plus 🙂

  • Ping : MD Blog » Blog Archive » QCon, Models and Integrism

  • 30 mars 2010 à 12 h 24 min
    Permalink

    @Greg : note que je n’ai pas dit que les modèles illisibles en question étaient bons 🙂 Ils se devaient de respecter un formalisme imposé assez peu naturel et, du coup, devenaient illisibles car ils perdaient en expressivité. Au travers du formalisme en question, ils étaient peut-être fonctionnellement juste, mais ce formalisme était un frein à leur utilisation. En fait, le premier travail d’analyse technique était de refaire d’autres modèles, plus compréhensibles et plus exploitables (avec les éventuels oublis ou erreurs possibles à chaque transformation manuelle).

  • 8 avril 2010 à 22 h 06 min
    Permalink

    Je ne comprends pas cette colère. J’ai assisté à la QCon, les 3 jours, et je n’ai vu ni « fatwa » ni intégrisme, en tout cas rien qui ne justifie tout le champ lexical déployé ici. Et pourtant, croyez-moi (ou pas) je suis assez sensible aux extrémismes, jusqu’à ne pas apprécier le terme d’Xtreme Programming tout en reconnaissant ses bienfaits pour avoir pratiqué la méthode pendant 3 ans. Car je crois que tous les extrêmes sont mauvais.

    J’ai assisté à la présentation de Uncle Bob, et je n’ai rien noté sur la modélisation, et mon collègue non plus.
    cf http://bamthomas.free.fr/badcode-craftmanship.png
    Il a du passer sur cette phrase (et encore, je vous fait confiance sur ce point) comme il le fait lors de certaines anecdotes, avec exagération pour maintenir son discours et son auditoire. Il faut préciser pour ceux qui ne l’ont jamais vu qu’il est très bon orateur, justement parce qu’il en fait des tonnes. Je me pose la question de votre focalisation sur cet aspect qui n’était certainement pas une partie importante, sinon je l’aurai noté.

    Il ne faut pas confondre conception émergente et absence de modélisation.

    Deux choses que j’ai retenues de la Qcon :
    – c’est l’adoption des tests automatiques (cf les tracks « how do you test that », avec les tests asynchrones, de charge, etc, et les nombreux sondages lors des confs sur les tests auto et le TDD qui voyaient beaucoup de mains levées). C’est à dire que c’est l’adoption d’un modèle empirique versus un modèle déterministe. En effet, comme vous le dites si bien, votre cerveau (et peut-être encore plus le mien), n’est pas capable de cerner la complexité inhérente au développement logiciel. Les couches utilisées lorsque l’on développe sont nombreuses (7 couches réseau pour la partie communication, les couches liées à l’exploitation de la machine, les couches graphiques, etc.). L’approche favorisée est donc : je ne sais pas prévoir avec certitude ce qui va se passer, alors je vais prouver au minimum que le programme fait bien ce qu’il est sensé apporter comme valeur au client par des tests, unitaires, d’intégration, fonctionnels, de charge. Je n’ai pas confiance non plus dans la stabilité de ces fonctionnalités dans les modifications de ce programme, alors je rééxécute les tests à chaque modification (commit) de la base de code. Ensuite, je m’arrange pour que ce code puisse évoluer sans que cela ne représente trop d’effort (et donc de coûts pour le client), alors je supprime le code qui ne sert pas, je supprime les duplications (pour ne pas faire plusieurs fois les mêmes choses), je renomme lorsque j’ai mieux compris les concepts. Mais dans toutes ces opérations, j’utilise les modèles, et je les maîtrise (cf Agile Modelling de Scott Ambler). C’est un *outil* de communication et d’abstraction. Mais comme tous modèles je sais que par essence, ils sont faux car au minimum incomplets, au maximum vite obsolètes.

    – la nécessité dans l’avenir de travailler sur du code ancien (et c’est déjà le cas). Ca fait 15 ans que je fais du développement logiciel, il m’est arrivé qu’à de rares occasions de partir « from scratch ». La majeure partie du temps c’était sur des applications existantes, 100000 lignes de code de C++ ici, 1 000 000 de lignes de code de C/C++ par là, 300000 lignes de code de java, 100000 lignes de code encore de Java/C++, voici les principaux exemples que j’ai rencontré. « Living and working with aging software » c’était l’excellente introduction qu’a faite Ralph Johnson (membre du GoF quand même, en terme de modélisation ce n’est pas rien), lors de la 2e journée. Il soulignait que lorsqu’un secteur industriel devient mature, il devient plus sensible au capital. A la fin du siècle dernier, c’était rapide, lors de l’émergence d’internet de devenir un acteur important (ce qui a provoqué cette fameuse bulle), à présent, pour aller marcher sur les platebandes d’amazon, ou google, c’est plus difficile. Car ils ont acquis un capital pendant toutes ces années. Quel est-il ? c’est le code, et Ralph Johnson ajoute « les structures sociales et techniques pour le comprendre ». Sans aborder la partie organisationnelle, dans les structures techniques il peut s’agir de guidage (code autodocumenté par ex), ou de modélisation j’imagine.

    Dans ces deux aspects, je comprends votre embarras par rapport à la modélisation, et peut-être est-ce là l’explication de ce vocabulaire inapproprié (allez faire un tour en Afghanistan pendant ne serait-ce que l’équivalent de la durée de QCon et on en reparle). Je ne veux pas troller sur code versus modèle, je veux dire que lors de la QCon, je n’ai absolument pas ressenti d’excès ou de comportements discriminants que ce soit M$ versus Java/opensource, langage fonctionnel versus OO, ou encore conception à priori versus design emergent.

    Il faut aussi comprendre que vous allez dans une conférence de développeurs, que ces gens font du code. Ils n’aiment pas trop qu’on génère le code à leur place. Le pari de l’avenir pour la plupart, c’est de monter en abstraction par des langages plus abstraits (Java est d’un niveau d’abstraction plus élevé que le C++ qui lui même l’est plus que le C qui est lui même plus que l’assembleur) pour être plus efficace, pas de générer du code. D’ailleurs dans sa conf — mauvaise d’ailleurs, Eric Evans est un bon écrivain mais mauvais orateur — sur 2015 « what will not change », Eric Evans soulignait les excès de l’application de DDD notamment par des outils de génération de code.

  • 9 avril 2010 à 17 h 18 min
    Permalink

    @Bruno Thomas
    Bonjour j’ai également participé à QCON et assisté à la plupart des conférences citées. Je confirme que Robert Martin et la plupart des intervenants de la track Software Craftmanship répétaient à l’envi que modéliser à l’aide d’un outil était au mieux inutile au pire une mauvaise pratique. J’ai réellement eu l’impression que dans leur bouche les termes de modélisation et surtout UML devenaient des gros mots.
    Cependant d’autres intervenants tels que Ralph Johnson ou Eric Evans étaient plutôt en faveur des pratiques de modélisation. Ralph Johnson a préconisé au minimum de faire de la rétro-ingénierie de code, Eric Evans est on le sait promoteur d’une approche basée sur la modélisation du domaine. Par ailleurs l’un des conférenciers de la Software Craftmanship, David Harvey, a critiqué cette approche un peu extrêmiste.
    J’ai réellement ressenti un fort décalage entre ces deux visions du développement. J’ai parfois l’impression en entendant certains gourous de l’agilité d’entendre des prêcheurs censés détenir la vérité ultime. Aujourd’hui il convient de faire du Test Driven Design. Hier c’était les patterns et la réduction des dépendances. Demain cela sera quoi ?
    Attention je ne remets pas en cause l’utilité du TDD ou des autres pratiques telles que le refactoring ou l’intégration continue. Ce que je critique c’est le fait de vouloir imposer une manière de faire et de considérer que les autres sont néfastes. TDD peut être une très bonne pratique mais elle ne doit pas devenir une excuse pour éviter de réfléchir ou faire de la conception.
    Comme le disait Ralph Johnson lors de sa conférence, il est probable qu’une application développée aujourd’hui sera encore utilisée dans 20 ou 30 ans. Il sera utile de disposer de tests. Sera-ce suffisant pour la faire évoluer, la maintenir, communiquer ?
    J’ai moi-même été passablement irrité d’entendre Dan North, que j’apprécie beaucoup par ailleurs, faire scander à la foule : « Comment fait-on de l’UML : toujours sur un tableau blanc ». Je ne suis pas un adorateur d’UML mais je persiste à penser qu’un bon modèle peut être extrêmement utile et que si l’on a pris le temps de le faire autant le garder et le partager.
    Attention de ne pas faire l’amalgame entre modélisation et génération de code. On peut tout à fait modéliser sans générer de code. Cependant s’il l’on peut générer toute la mécanique et se concentrer sur l’essentiel on peut gagner beaucoup en qualité et en temps.
    Pour terminer, n’oublions pas que l’informatique manipule de l’information. Cette information est multiple et complexe. Il est indispensable pour qui veut tenter de maîtriser (au moins un peu) cette complexité de se doter d’outils et de méthodes. Cela peut sembler archaïque ou illusoire voire utopique. On peut effectivement penser que cette démarche est vouée à l’échec et se targuer d’empirisme vs le déterminisme. Cela me rappelle les shadocks (pour les anciens) qui construisaient une fusée. Ils avaient estimé avoir une chance sur un million de faire décoller leur fusée, alors ils se dépéchaient de rater leurs 999.999 premiers essais.

  • 9 avril 2010 à 22 h 52 min
    Permalink

    @Yves Connétable
    Bonsoir,

    Je ne veux pas vous convaincre. Cela dit, quand on parle de TDD comme Test Driven Design on peut se demander la compréhension que vous en avez. Et d’ailleurs, le lapsus est sans doute révélateur.

  • Ping : La Grappe » Alors, cette QCon 2010 ?

  • 12 avril 2010 à 9 h 24 min
    Permalink

    @Bruno Thomas
    Bonjour Bruno,

    je n’ai pas à être convaincu. Je pense depuis longtemps que le TDD est une très bonne pratique. Ce que je dis c’est qu’il ne faut pas penser qu’il sera la solution à tous les problèmes. Dans beaucoup de situations une réflexion préalable à l’aide de modèles est très utile, voire indispensable.
    Quand au lapsus il révèle effectivement ce que je pense de cette pratique lorsqu’elle est bien appliquée : elle peut permettre lorsqu’elle est utilisée conjointement avec du refactoring de faire émerger une bonne conception. Cela reflète effectivement ce que je pense : coder c’est concevoir. A ce propos l’exemple de TDD sur les nombres de fibonacci était très intéressant.
    Au delà de la querelle sur les termes j’ai vraiment ressenti un hiatus entre les tenants de l’approche « Software Craftmanship » assez extrêmistes et les intervenants tels que Ralph Johnson ou Eric Evans, voire Martin Fowler dans une moindre mesure, qui préconisent de ne pas s’intéresser qu’au code et à sa qualité mais également à la connaissance du domaine et du métier des utilisateurs. Ces deux approches ne sont absolument pas incompatibles, d’ailleurs les démarches telles que le BDD (les trigrammes finissant avec au moins deux D ont pris le relais des trigrammes en OO) essaient de réconcilier ces approches.
    Je sais bien évidemment que des personnes comme Robert Martin ou Dan North sont des personnes extrêmement intelligentes et qui des opinions plus nuancées que leurs présentations ne pourraient le laisser croire. Cependant une conférence comm QCON a beaucoup d’influence sur la communauté des développeurs (au sens large), ne serait-ce qu’au travers des diffusions des vidéos. Le message est donc important. Au sortir d’une telle conférence certains pourraient être convaincus que seule une approche orientée par le code peut donner de bons résultats.

  • 12 avril 2010 à 19 h 46 min
    Permalink

    @Yves,

    Re-bonsoir,

    Vous ne m’avez pas compris, je ne parlais pas de vous convaincre sur les bienfaits du TDD, mais sur la manière de concevoir le développement par le design ou par le code.

    Je ne veux pas vous convaincre car il y a encore 5 ans j’avais aussi une approche très centrée sur le design et la modélisation, et même quelqu’un comme moi ne m’aurait pas convaincu 🙂 Donc nous perdons tous les deux notre temps à argumenter.

    Le but de mon post n’était pas de convaincre l’ensemble de la communauté de lecteurs de ce blog sur l’aspect fondamental du design émergent (ou evolutionary desing : cf http://martinfowler.com/articles/designDead.html), et de l’inutilité des CASE tools (je m’associe volontiers à ce que disait Dan North), mais de contre balancer ce retour à chaud réducteur de ce qu’a été la QCon.

    Pour être plus précis, bien que j’aie toujours été intéressé par le design et que je le sois toujours, je n’ai pas ressenti d’ostracisme sur les pratiques de modélisation, et je trouve la réaction de cet article bien plus extrême que ce qu’elle est sensée dénoncer. C’est similaire à ce que j’ai pu entendre de DBA’s de bases relationnelles confrontés au mouvement « No-SQL ». C’est l’absence de remise en question et la dénonciation de l’extrémisme des autres pour se protéger que je trouve malhonnête. Et comme l’article paraît en bonne place en recherche google blog sur la qcon je préférais préciser que ce n’était pas nécessairement une réaction partagée par tous.

    Voici ce que j’ai retenu de ces 3 jours si ça peut vous intéresser :
    http://www.lagrappe.net/alors-cette-qcon-2010

    Cela dit, pour vous dire qu’on partage des choses :
    Oui « Software Craftmanship » est très centré sur des pratiques d’ingénierie, je m’associe comme vous à ce que disait Martin Fowler, en trouvant que c’est anormal si vous demandez à un développeur ce qu’il fait et qu’il vous répond par des technologies, méthodologies ou pratiques, avant de préciser pour-quoi il le fait. Mais si vous faites du MDA et que vous allez à un track sur Software Craftmaship, c’est comme si un frontiste allait à colloque du parti communiste (ou l’inverse pour ménager les susceptibilités), faut pas vous étonner de ne pas aimer ce que vous allez entendre.

    Bien sûr également que le TDD n’est pas incompatible avec l’intérêt pour le domaine métier et la modélisation c’est exactement ce que je disais dans mon premier post. De la modélisation, en TDD on en fait tout le temps, et on se doit de la maîtriser. J’ai lu DDD de la première à la dernière page, et ce que j’en retiens c’est l’ubiquité de langage, et le knowledge crunching, capturer l’essence des concepts métiers pour montrer l’intention. Mais Eric Evans ne dit pas que la valeur du développement réside dans les modèles en eux même, il dit que dans 5 ans on fera toujours du design, et là dessus il ne prend pas beaucoup de risques. La valeur, c’est le code. Les modèles, la plupart du temps on les fait à plusieurs pour communiquer (entre devs, avec des spécialistes métier) et on les efface ou on les jette (cf Scott Ambler et Martin Fowler).

    Cela dit, je crois avoir bien expliqué les motivations de ma réaction, je vous laisse, si vous le souhaitez le mot de la fin.

    Bruno

  • 12 avril 2010 à 20 h 47 min
    Permalink

    @Yves
    Quand je lis « [la pratique du TDD] peut permettre lorsqu’elle est utilisée conjointement avec du refactoring de faire émerger une bonne conception », je m’étrangle.

    Une précision pour tous : le TDD c’est :
    1) poser un test indiquant ce que l’on veut obtenir du (futur) programme. Il est rouge (échoue).
    2) passer le test à vert le plus rapidement et naïvement possible
    3) remanier le code (refactoring)
    4) goto 1

    Le refactoring FAIT PARTIE du TDD, c’est une partie fondamentale qui permet justement l’émergence du design. Vous ne pouvez pas décorreller TDD du refactoring, c’est la même chose.

  • 13 avril 2010 à 8 h 16 min
    Permalink

    @Bruno Thomas
    Ce n’est pas la peine de s’étrangler. Le refactoring consiste à faire évoluer à périmètre fonctionnel équivalent un code existant. Il intervient donc dans un second temps et a pour objectif d’améliorer la qualité de ce code, notamment sa conception.
    Mais je pense que l’on s’écarte du débat. Les pratiques de modélisation sont elles ou non incompatibles avec les démarches agiles comme le prétendent leurs zélateurs ?
    Je pense qu’il est néfaste de laisser croire qu’une seule démarche est possible pour régler tous les problèmes. Les deux démarches sont absolument compatibles. En revanche en fonction des situations, des qualités que l’on cherche à atteindre, de l’organisation, bref en fonction des exigences et des contraintes, on peut donner plus ou moins d’importance à une pratique.

  • 26 avril 2010 à 22 h 49 min
    Permalink

    @Bruno Thomas
    Je ne voudrais pas avoir l’air de réchauffer un vieux Troll mais, en tant qu’auteur de l’article qui a suscité ces échanges, je me dois tout de même de répondre directement.
    D’abord, merci d’avoir pris le temps et la peine de rédiger vos commentaires étayés et intéressants.
    Comme vous l’avez noté, il s’agit, au départ, d’un billet d’humeur, reflétant mon opinion personnelle à mon retour de Londres. Malgré tout, les discussions que j’ai pu avoir avec d’autres participants m’ont montré que ces sentiments étaient partagés (cf. les réponses que vous a faites Yves Connétable).
    C’est la troisième année que j’assiste aux QCon et chaque année, ce sentiment d’ostracisme est plus fort. Et le ton de vos commentaires le confirme : considérer la modélisation comme une discipline à part entière du génie logiciel est, pour certains, quelque chose de complètement incongru, voire d’inaudible.
    Lorsque j’affirme la phrase suivante : « il est possible de générer efficacement une application à partir d’un modèle », je pense que vos oreilles frisent, comme celles de la plupart des conférenciers et des participants des QCon. Pourtant, c’est une réalité que vit au quotidien une part importante des développeurs.
    Ce qui m’énerve, c’est que cette partie du monde du développement soit complètement exclue (c’est ce que j’ai ressenti les deux premières années), voire stigmatisée. D’ailleurs, je suis sur que vos premières réactions à la phrase que j’ai écrite plus haut ont été : « c’est impossible, les générateurs de code sont des usines à gaz, le code généré n’est pas maintenable, le code bien écrit à la main est plus performant, mieux testable, plus facilement refactorable ». Je suis sur que, si j’affirme cela, je suis immédiatement catalogué au mieux « doux rêveur » au pire « vieux réac » (la version courte de « développeur cachant son incompétence derrière des outils de génération de code »). Je ne pense pas que ce soit de la parano. C’est l’opinion ultra-dominante dans des conférences comme QCon, mais pas partout (cf. par exemple des conférences comme Models, Code Generation, MD Day ou les blogs de Markus Völter ou de Johan den Haan) !
    Mon propos c’est que l’utilisation de modèles pour produire du logiciel est :
    1. Une pratique courante
    2. Compatible avec les bonnes pratiques de l’agilité
    3. Négligé, voire méprisé par une partie de la communauté.
    Et je le redis, j’adore aussi les QCon 🙂 !

  • 7 mai 2010 à 20 h 52 min
    Permalink

    @Gregory

    Simplement 3 choses :
    – vous n’avez toujours pas compris le fond du problème : la conception déterministe que vous défendez et la conception empirique que les gens de la QCon, dont je fais partie défendent, s’opposent. Et les statistiques donnent tord au déterminisme puisque 80% des projets informatiques échouent en budget ou délai (dans leur ensemble mais on peut considérer que seule une petite minorité des projets est gérée par des pratiques d’ingénierie empiriques) .
    – je vous renvoie à un livre qui vient de sortir et que je viens de me procurer (je n’ai pas encore lu). Il traite très bien de ce dont nous parlons : « The Design of Design » par Frederick Brooks (oui, celui qui a écrit The Mythical Man-Month). Vous trouverez en chapitre 8 très bien expliqué cette opposition : « Rationalism versus Empiricism in design »
    – posez-vous peut-être la question de pourquoi dans des rencontres rassemblant la fine fleur des développeurs, qui ont une certaine expérience, le modèle que vous défendez est autant décrié (je sais on pourra ensuite parler de la raison de la majorité).

    Sur ce, je vous laisse à vos modèles, bonne continuation.

    Bruno Thomas

  • Ping : Quelle forme pour mon modèle ? « Redsen

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *