Les métaphores en développement logiciel

Les métaphores font partie des outils de communication les plus puissants dont nous disposons en tant qu’êtres humains et ingénieurs logiciels. En effet, les métaphores nous permettent d’appliquer à un domaine complexe l’intuition développée dans un autre domaine plus familier. Cette façon de penser est particulièrement utile pour aborder les domaines abstraits.

Il n’est donc pas surprenant que le génie logiciel soit un domaine où les métaphores et le langage métaphorique sont courants. Nous parlons de dettes, de factories, de crashs, de bugs, de worms… Toutes ces comparaisons nous permettent de mieux expliquer le développement logiciel. Alors, que vous soyez familier ou pas avec tout le langage technique que l’on retrouve en ingénierie logicielle, je vous invite à découvrir dans cet article de blogue quelques-unes des métaphores les plus répandues pour expliquer l’univers complexe du développement.

Pourquoi les métaphores sont-elles utiles?

Lorsqu’on est confronté à des problèmes difficiles et complexes, il peut être tout aussi difficile de résoudre le problème que de simplement communiquer le contexte de manière bien posée. La métaphore aide à :

• Conceptualiser les problèmes
• Mieux comprendre les choses
• Résoudre les problèmes
• Communiquer avec les parties prenantes

D’où viennent ces métaphores?

L’utilisation de métaphores en développement logiciel ne date pas d’hier. Pour le plaisir, en voici quelques exemples :

• Le développement logiciel est une science ; David Gries, principalement connu pour ses livres The Science of Programming (1981) et A Logical Approach to Discrete Math (1994)
• Le développement logiciel est un art ; Donald Knuth, aussi appelé «le père de l’analyse des algorithmes»
• Le développement logiciel est un processus ; Watts Humphrey, aussi appelé «le père de la qualité logicielle»
• Le développement logiciel c’est comme conduire une voiture ; P. J. Plauger, programmeur informatique, et Kent Beck, créateur de la programmation extrême (1996)
• Le développement logiciel est un jeu ; Alistair Cockburn, l’un des initiateurs du mouvement Agile dans le développement logiciel
• Le développement logiciel est un bazar ; Eric Raymond, développeur logiciel
• Le développement logiciel c’est comme le jardinage ; Andy Hunt, l’un des 17 auteurs initiaux du Manifeste Agile, et Dave Thomas, inventeur des expressions «Code Kata» et «DRY» (Don’t Repeat Yourself)
• Le développement logiciel c’est comme le film Blanche-Neige et les sept nains ; Paul Heckel, auteur du livre The Elements of Friendly Software Design (1994)
• Le développement logiciel c’est comme l’agriculture, la chasse aux loups-garous ou se noyer avec des dinosaures dans une fosse de goudron… ; Fred Brooks, principalement connu pour avoir dirigé le développement de la famille d’ordinateurs System/360 d’IBM et du progiciel OS/360

Même si je n’ai rien contre les loups-garous et les dinosaures, vous comprendrez que toutes les métaphores ne sont pas égales. Certaines d’entre elles deviennent plus connues et répandues dans l’imaginaire collectif lorsqu’elles rejoignent un grand groupe de développeurs. Il y en a notamment quatre qui ont fait leurs preuves pour démocratiser le développement logiciel et amener une meilleure compréhension des parties prenantes. Le développement logiciel, c’est comme:

1. Construire un bâtiment
2. Planter un jardin
3. Apprendre l’artisanat
4. Gérer des finances

Développer un logiciel comme on construit un bâtiment

Une maison sans fondation, ça ne se fait tout simplement pas : c’est la première étape non négociable. Imaginez que votre entrepreneur vous dise : « Faire la fondation prendra trois semaines de plus, car on est en pénurie de ciment… Mais puisqu’on vous a promis la maison pour la date X, on va prendre un raccourci et faire la fondation en bois. » Que diriez-vous?

Alors pourquoi seriez-vous prêt à faire de tels sacrifices lorsqu’il est question de construire votre produit logiciel? Il arrive souvent en développement de logiciel que l’on souhaite passer directement au clavier, à oublier les tests et négliger de faire un minimum d’analyse : on est prêt à sacrifier nos fondations afin de respecter nos échéances. En tant qu’ingénieurs de logiciels, notre rôle est de défendre les fondations et de faire comprendre au client l’impact de changer nos bonnes pratiques au profit d’une date d’échéance établie à partir d’estimés (je répète que ce sont des estimés!) dans un contexte évolutif. Si le contexte change (et il va changer!) ou qu’on découvre des bloquants imprévus, il faut absolument revoir le plan de match ou repousser la date de livraison. Ce qu’il ne faut surtout pas faire, c’est couper dans les bonnes pratiques et la qualité.

On voit souvent les développeurs comme des «codeurs» : des gens qui doivent être à leur clavier et taper du code pour être rentables. Mais comme en construction, il faut prendre le temps d’analyser les choses, d’aiguiser nos outils, de penser à des solutions alternatives qui pourraient être moins chères et moins complexes, et de s’assurer que chacune de nos actions amènera le meilleur rapport qualité-prix.

Cette métaphore ne considère toutefois pas l’agilité avec laquelle le développement logiciel doit opérer. En effet, le développement d’un logiciel peut commencer avant que les besoins de l’entreprise ne se concrétisent et il est donc possible que ces besoins soient modifiés après le début de la construction du bâtiment, voire après la construction d’une douzaine d’étages. C’est probablement pourquoi la métaphore a évolué vers un chantier plus itératif : le jardinage.

Développer un logiciel comme on plante un jardin

Un système informatique est comme un jardin : c’est vivant. On ne sait pas à quelle vitesse ça va aller et il y a beaucoup d’impondérables. Cependant, on connaît les conditions favorables pouvant mener au résultat escompté.

Par exemple, si les températures sont dans la normale, que le sol est riche et que je prends soin de mes boutures, je peux prédire que mon plant atteindra probablement six pouces au mois de juin. Mais ça reste une approximation! Et il se peut que le plan(t) change en cours de route. En jardinage, on s’attend à ce que beaucoup de choses moins ordonnées se produisent, par exemple qu’une plante devienne trop grande, meure ou nécessite un entretien constant.

En développement logiciel, c’est la même chose. On débute avec une idée du résultat souhaité, on met tout en place pour y arriver, mais on s’adapte aux nouveaux besoins qui émergent à chaque nouvelle livraison.

«Gardening is planting, pruning, and killing weeds, in software development, it’s like coding, detecting code smells, preventing code rot, refactoring.»
— Park Sehun

Développer un logiciel comme on apprend l’artisanat

Dans les dernières années, j’ai observé une évolution vers la notion de «craftsmanship» avec des mentors pour partager les bonnes pratiques.

Assurer la pérennité de l’industrie passe par le coaching des professionnels juniors pour les amener à un autre niveau et que les connaissances se propagent.

Le développement logiciel s’est beaucoup démocratisé dans les dernières années, mais ce ne sont pas tous les développeurs qui ont la même rigueur que les premiers informaticiens, donc le niveau de qualité des développeurs se dilue. Puisque le nombre de développeurs double chaque cinq ans, la moitié des développeurs ont moins de cinq ans d’expérience. Il est donc important d’avoir un bon mentor pour acquérir les bases solides de la profession. Sans notion de «craftsmanship» où les anciens encadrent les nouveaux, on risque de perdre le contrôle et, considérant que toutes nos vies dépendent de l’informatique aujourd’hui, l’encadrement est primordial.

Développer un logiciel comme on gère des finances

La métaphore de la dette technique, inventée par Ward Cunningham, est une analogie financière. Emprunter de l’argent est un moyen rapide d’obtenir de nouveaux fonds et indirectement d’autres ressources. Comme la plupart d’entre nous le savent, lorsqu’on emprunte de l’argent, il faut le rembourser ultérieurement. Il faut également être prêt à payer un taux d’intérêt. Si l’on continue à emprunter de l’argent, on finit par devoir payer un taux d’intérêt si élevé qu’on ne peut plus se le permettre.

Si on lance un logiciel, rapidement et sans ménagement, en prenant des raccourcis encore et encore, on finit par se retrouver dans une situation où le code devient impossible à utiliser et à maintenir, à moins de le nettoyer. L’approche rapide est analogue à un emprunt d’argent : on a maintenant une dette technique importante. Avec une telle dette sur les bras, on sera terrifié à l’idée d’ajouter de nouvelles fonctionnalités au code (puisqu’on ne le comprend pas vraiment), et l’on devra très probablement passer beaucoup de temps à corriger les défauts (alias les bogues) pour éviter des catastrophes (aka la faillite).

L’analogie du remboursement dans le développement de logiciels est le processus de refactoring. En surveillant constamment les signes de dégradation (les «smells»)  et en nettoyant constamment le code, on effectue des remboursements réguliers afin de comprendre le code et de le garder malléable pour le futur.

Le côté sombre de la force

Si les métaphores ont plusieurs avantages et nous aident à illustrer des concepts abstraits en se rattachant au concret, il existe certaines lacunes lorsqu’on utilise la comparaison. Les métaphores sont d’excellents outils de communication, pour autant que nous soyons conscients de leurs limites et que nous les prenions avec un grain de sel.

Rappelez-vous d’observer le lien mis de l’avant par l’auteur, sans utiliser les métaphores à d’autres fins. Inutile de s’approprier les métaphores dans un nouveau contexte qui sort du besoin initial de comparaison, où l’on risquerait de faire parler la métaphore comme bon nous semble. Il est très facile de tirer de fausses équivalences entre le génie logiciel et ce que nous connaissons déjà.

De plus, les métaphores sont elles-mêmes limitées dans certaines circonstances, par exemple si la cartographie est inappropriée ou inadéquate ou si l’on adhère de manière trop rigide à la métaphore, de sorte qu’elle limite la réflexion.

« Metaphor and analogy can be helpful, or they can be misleading. It all depends on whether the similarities the metaphor captures are significant or superficial. »
— Herbert Simon, The Architecture of Complexity, 1962

En tant que consultants, notre travail consiste à aider les clients à comprendre notre valeur, et cela passe parfois par l’analogie, mais nous devons éliminer les divergences et nous assurer que les comparaisons sont justes et précises pour communiquer réellement la valeur d’une manière familière.

Ressources pour aller plus loin :

• Code That Fits in Your Head (chapitre 1), un ouvrage pour écrire du code à un rythme soutenable et maîtriser la complexité qui fait que trop de projets logiciels deviennent incontrôlables.
• The Software Craftsman (chapitre 3), qui explique comment adopter cet état d'esprit de l’artisan logiciel pour atteindre des niveaux d'excellence technique et de satisfaction client sans précédent.
• Mikado method (annexe A), décrivant une méthode pragmatique, simple et empirique pour planifier et réaliser des améliorations techniques sur un système logiciel existant.
• Modern Software Engineering (chapitres 1 et 2), dans lesquels David Farley met en lumière les principes durables qui sont au cœur du développement efficace de logiciels.
• Code Complete, dont le chapitre 2 est entièrement dédié aux métaphores pour enrichir la compréhension du développement logiciel.