Mauvaises conception de la conception

Mon exposé sur les pratiques Agiles liées à la conception a été très bien accueilli à Reykjavik, dont je suis revenu hier très fatigué mais aussi très content.

Mon principal objectif était de faire le lien entre les connaissances accumulées depuis quelques décennies sur les biais cognitifs et l'activité de conception ou "design". J'y ai déjà fait allusion dans mes billets précédents évoquant la danseuse et les bugs du cerveau.

Le point sur la conception

Cet exposé était aussi l'occasion de faire le point sur ce qu'ont été les apports du mouvement Agile au discours sur la conception.

Le terme anglais "design" est très surchargé, que ce soit dans la vie courante (une brosse à dents ou un siège peuvent "être design", c'est une discipline artistique mais aussi industrielle) ou dans le champ professionnel du logiciel, où il peut suggérer aussi bien l'ergonomie (product design, interaction design), l'esthétique (graphic design), la représentation de l'information (information design), ou enfin la conception logicielle à proprement parler.

La terminologie francophone laisse peut-être légèrement moins de place à l'ambiguité, quand on parle de "conception" ce sont le plus souvent les programmeurs qui se sentent concernés.

Avis de décès?

En 2000 paraissait un article important de Martin Fowler, intitulé "Is Design Dead?". A l'époque on ne connaissait que peu Scrum, le "buzz" se concentrait autour d'Extreme Programming et ni l'un ni l'autre de ces discours n'était encore appelé "Agile" - ce n'est qu'à partir de 2001 que le terme issu de la rencontre de Snowbird sera adopté.

On sortait d'une période qui avait vu UML triompher après un long et intense débat sur les notations formelles graphiques, bien illustré dans ce dessin. Pour une grande partie de la profession, "UML" et "conception logicielle" étaient devenus des synonymes.

Fowler relevait l'une des principales critiques à l'égard d'Extreme Programming, auquel on reprochait d'être "centré sur le code". Et de constater le rejet par Extreme Programming non seulement d'UML mais de plusieurs dogmes tout aussi fortement associés à l'idée de conception: le principe d'une "phase de conception" venant en amont de la phase de programmation, celui d'organiser le développement autour de "frameworks" ou de "patrons de conception".

Pour certains, selon Fowler, Extreme Programming semblait vouloir en finir avec la conception. Martin Fowler était en bonne position pour arbitrer ce débat: il était non seulement le co-auteur d'un bréviaire sur UML qui avait connu des ventes record, mais également d'un livre sur le "refactoring" connu comme l'une des pratiques clés d'Extreme Programming, et considéré commel'une des figures tutélaires de cette mouvance.

Non, concluait Fowler, Extreme Programming n'appellait pas à la mort de la conception ni n'annonçait son décès; et Fowler d'attester, en analysant de près les recommandations effectivement émises par Extreme Programming, que la conception y restait une préoccupation majeure, et que ses critiques avaient eu une vision caricaturale de la conception.

Trois mises au point sur la conception

Extreme Programming, et à sa suite le mouvement Agile, ont ainsi permis de rectifier, ou de commencer à rectifier, un certain nombre d'idées fausses sur la conception, et trois exemples me paraissent particulièrement importants.

La conception n'implique pas nécessairement une notation formelle qui s'exprime visuellement. Cette idée a longtemps été le cheval de bataille des tenants d'UML, et le triomphe d'UML au tournant de l'an 2000 était partiellement le triomphe de cette idée. Par un raccourci de pensée jamais justifié "visuel" était présenté comme synonyme de "supérieur": parce que UML permettait de modéliser visuellement, il était un meilleur véhicule pour parler de conception. Corollairement, le code source lui-même, n'étant que textuel, ne pouvait pas être un support approprié pour exprimer des notions de conception.

Le succès des approches Agiles a contribué à remettre les pendules à l'heure. Toutes les modalités d'expression - visuelles, textuelles, ou autres - ont leur place pour parler de conception. La question est moins de savoir comment représenter le résultat des activités de conception, mais plutôt de savoir qui doit y participer, et par conséquent où elles doivent se dérouler. L'approche privilégiée par les équipes agiles est celle de la "modélisation agile" ou des "sessions rapides de conception": cela se passe au tableau blanc, on doit impliquer les développeurs chargés de la réalisation, et s'il faut conserver une trace permanente une photo du tableau suffit largement.

La conception n'est pas nécessairement une activité qui précède la programmation. Avec UML c'est aussi une approche en phases du projet de développement logiciel qui prévaut. L'accent a été mis sur des outils permettant aux architectes de réaliser un document de conception détaillé en amont du développement, et (comme on dit alors) de le "balancer par-dessus le mur" aux programmeurs qui doivent en suivre les recommandations. C'est une vision caricaturale et inefficace des activités de conception qui n'a que peu de rapport avec la réalité du terrain.

La démonstration en est faite par Fowler lui-même dans son ouvrage sur le Refactoring, dont le sous-titre est "améliorer la conception d'un code existant". C'est un travail rigoureux, argumenté, basé sur un travail de thèse doctorale, celle de Bill Opdyke; il amène Fowler à prédire, et l'avenir lui donnera raison, l'intégration du refactoring automatisé dans les éditions futures des outils de développement.

La conception est une activité collective, pas exclusivement individuelle. Le discours sur la conception est dominé par la description de principes, d'heuristiques, de règles. Grammaticalement, la forme la plus usitée est celle de l'impératif: "évitez les classes contenant un trop grand nombre de méthodes publiques". On n'y prend presque pas garde mais une hypothèse, implicite et jamais remise en question, sous-tend la quasi totalité de ce discours: il s'adresse à une seule personne (Le Concepteur), travaillant de manière isolée. Elle se confirme facilement en examinant des sites d'entraide du type StackOverflow: les questions sont systématiquement de la forme "Comment dois-je m'y prendre pour..."

L'approche Agile suggère une autre démarche, dans laquelle le "nous", le collectif, l'équipe prennent le pas sur l'individu. La question n'est plus "quelle est la bonne conception dans cette situation", mais "sur quelle conception pouvons-nous être d'accord". Non pas "quel principe de conception prévaut", mais "quels critères nous permettent de décider entre deux propositions individuelles (ou mieux encore en faire la synthèse)".

L'enjeu de la conception n'est pas, d'une façon un peu scolaire, de donner individuellement la réponse correcte; il est pragmatique et économique, et consiste à générer plusieurs propositions et décider, entre ces diverses alternatives, laquelle offre les conséquences les plus désirables pour le projet. Cette décision engage la responsabilité de chacune des personnes qui devront ensuite assurer la maintenance du code, elle est donc une négotiation collective... sans pour autant être nécessairement égalitaire: les compétences en matière de conception ne seront que rarement partagées dans l'équipe de façon homogène.

Changer de point de vue

Sur ces trois points au moins, le discours Agile a contribué à chasser les images d'Epinal de la conception et rétablir une perception plus juste de cette activité. Reste que ces trois erreurs avaient à mon sens une origine commune, l'erreur de projection que je dénonçais dans un précédent billet: et malheureusement, y compris au sein de la communauté Agile, nous continuons à commettre cette erreur en parlant exclusivement de propriétés du code telles la duplication, la complexité, les heuristiques SOLID, les métriques de conception, etc.

Tout comme la dette technique, la conception, bonne ou mauvaise, n'est pas exclusivement une propriété du code source (ou des documents et autres artefacts qui l'entourent), et se focaliser sur les produits de l'activité de développement, c'est faire l'impasse sur la moitié de la question: le fonctionnement cognitif humain et ses limites.

Reykjavik, Prezi, conception Agile

Jeudi prochain, destination: Reykjavik! Le choix du coeur, ayant beaucoup apprécié l'Islande lors de vacances passées là-bas il y a deux ans, et promis d'y revenir; mais également un coup de pouce à une communauté Agile très dynamique.

J'avais bien apprécié l'atelier sur la pensée visuelle proposé par Benoit Gantaume (Agilidée, partenaire de l'Institut) lors de l'étape Nancéenne de l'Agile Tour et je m'étais promis de mettre en oeuvre les outils présentés à l'occasion d'un exposé pour une conférence.

La session avec laquelle je "tourne" actuellement, "Quarante ans de crise, dix ans d'agilité, et après" est largement constituée des sujets que j'ai traité récemment sur ce blog, qui proviennent eux-mêmes des réflexions qui ont motivé le lancement de l'Institut; elle n'est pas vraiment pertinente pour mes amis Islandais (et une précédente expérience m'a appris que le caractère Nordique peut être impatient avec ce qui ne lui semble pas pertinent: c'est mon unique et cuisant souvenir d'un exposé où une bonne partie de la salle a "voté avec ses pieds").

J'avais donc proposé un sujet sur les pratiques Agiles liées à la conception. Je souhaitais apporter une perspective un peu différente sur ce sujet: que nous a appris le mouvement Agile sur la conception, quelles pratiques sont utiles dans ce domaine et pourquoi, comment la prise en compte du non-technique et du "facteur humain" en Agile éclaire-t-elle notre compréhension de cette activité, vers quels sujets scientifiques nous pousse-t-elle à nous intéresser?

Depuis quelque temps je voulais aussi sortir de l'ornière "PowerPoint" (en l'occurrence Keynote puisque je suis un "Apple fanboy", mais c'est du pareil au même) mais je ne me sens pas encore à l'aise, lorsque j'aborde des sujets un peu théoriques, avec un exposé sans aucun support visuel. D'expérience, mon auditoire est composé de personnes ayant des préférences cognitives diverses: certains sont plutôt visuels, d'autres plutôt auditifs, d'autres kinesthétiques. Je cherche à présenter le même contenu sous plusieurs formes pour m'assurer que le maximum de personnes en retirent l'essentiel.

J'avais entendu parler de Prezi (et vu une présentation de Jonathan Perret utilisant cet outil à Agile France 2010), j'ai saisi l'occasion pour expérimenter.

Mon retour, façon Perfection Game: j'attribue largement 6/10, Prezi tient ses promesses de dépasser le carcan suranné du "slideware" directement hérité du projecteur de diapos (que mes parents avaient rangé dans un placard pour ne jamais le ressortir alors que j'avais, disons, 8 ou 10 ans). A la place, et après un démarrage très déroutant, on goûte un vrai sentiment de liberté devant le canevas sans limite et la possibilité de zoomer en avant, en arrière à l'infini (presque, j'ai réussi à me faire taper sur les doigts parce que ma présentation commençait à faire concurrence à "powers of ten" en termes de niveaux parcourus). On se sent vraiment incité à penser visuellement, à organiser spatialement des idées jetées pèle-mèle, à les hiérarchiser par la taille. Je me suis même pris à créer des jeux de mots visuels, alors que c'est tout sauf mon langage de prédilection!

Pour avoir 10/10 il faudrait corriger quelques défauts d'ergonomie, mineurs et pas bloquants mais très, très frustrants par moments; il faudrait pouvoir copier-coller plus facilement entre présentations (à mon avis Prezi a loupé une grosse occasion d'exploiter la dimension "sociale" de leur outil, en encourageant les auteurs à se piquer des éléments réutilisables); il faudrait un peu plus de liberté dans le choix des polices et des couleurs de fond.

Mon premier Prezi est en ligne (c'est la règle du jeu, la gratuité de l'outil est au prix du partage, je trouve ça très bien mais encore une fois on peut regretter que ça ne soit pas mieux exploité), si vous avez envie de jeter un coup d'oeil, vos retours seront les bienvenus.