Développeur informatique : sommes-nous considérés comme un centre de dépense ?

En tant que développeur, une question fatidique me vient à l’esprit à chaque fois que je commence à faire des estimations critiquées dans le but d’avoir un time-to-market concurrentiel :  sommes-nous considérés comme un centre de dépense ?

Il est vrai que certaines entreprises et certains experts métiers portent cette vision dont nous sommes en partie responsable. En effet, certaines pratiques que nous exerçons séparent ces deux mondes : le métier et la technique. Ces deux mondes qui devraient pourtant collaborer fortement pour n’en former qu’un seul, se trouvent parfois trop éloignés. 

Quelles sont ces pratiques  qui poussent les entreprises et les experts métier à avoir cette vision  ? Quelles sont les causes principales et enfin comment œuvrer pour changer les choses ? C’est ce que Vaugh Vernon, Craftsman accompli, a présenté dans son talk oDDs and enDDs lors de la conférence DDD Europe en 2016. Au travers de cet article, je vais essayer de répondre à cette problématique en me basant sur ce talk inspirant. 

Quand on ne parle QUE de la technique

Une forte collaboration est synonyme d’une discussion, d’un atelier ou d’une pratique heuristique amenant un Craftsman à découvrir le monde fonctionnel. On constate pourtant que généralement, un développeur a tendance à discuter d’une solution technique pour résoudre un problème métier.  C’est le cas, par exemple, quand les bases de données deviennent le centre d’intérêt de ses parties prenantes. D’un côté, nous avons le développeur qui pense pouvoir résoudre un problème métier grâce à la base de données. De l’autre, nous avons des experts du domaine qui référencent chaque projet à sa base de données déployée. C’est ainsi qu’on déporte un problème concret vers une problématique technique. 

Entre autres, au lieu d’être considérés comme des partenaires ayant le même objectif, celui d’apporter une meilleure solution fonctionnelle, nous poussons l’expert métier à nous voir comme des Technlogy Addicts. Cette idée « d’accros à la technologie » se confirme par l’abus d’usage des Buzz Words, vous savez, ces mots dont les développeurs usent et abusent. Par exemple, il y a encore quelques années, on entendait partout parler de Big Data, c’était alors le Buzz Word du moment. Maintenant, le fait de prononcer les mots clé : Machine Learning, Deep Learning ou encore Intelligence artificielle contribue à faire de vous « un développeur cool« . 

Cet abus de langage ne fait que confirmer cette vision. Au lieu de collaborer ensemble pour résoudre un seul et unique problème métier, nous nous trouvons dans un monde à part, très loin de celui des experts métier, parlant ainsi un autre langage tout en essayant de résoudre un deuxième problème technique. 

Quand “les outils de collaborations” freinent la collaboration 

Cette collaboration est censée fonctionner dans les deux sens. Malheureusement, quand un expert métier passe énormément de temps derrière son écran à écrire des spécifications sous différents formats (du texte, un schéma ou des requêtes de base de données), il ne fait que contribuer à la séparation de ces deux mondes.

« La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face. » – Manifeste Agile 

D’ailleurs, ce temps dédié à la rédaction de spécifications peut être mieux exploité avec un meilleur dialogue entre les experts métier et l’équipe de développement. Ainsi, les devs auront une vision plus claire du problème métier tout en partageant un seul langage commun. 

Effectivement le fait de privilégier le face à face ne peut que renforcer cette collaboration bidirectionnelle. 

Quand le nommage s’en mêle

Le monde de la technique est truffé de langages informatiques. Qui plus est, le code fourni est dénué de tout langage fonctionnel reflétant le problème et la solution à produire. Une situation qui est due à un abus de langage dont chaque développeur traduit chaque mot métier à un autre technique. Aucun expert métier ne peut donc s’y retrouver ! Même l’équipe de développement a parfois du mal. 

Voulant à la base créer une solution fonctionnelle, l’équipe de développement ne fait alors qu’accumuler des “bugs” en essayant d’implémenter des solutions techniques pour des problèmes métiers. Par conséquent, le nom que l’on choisit pour une méthode, un paramètre ou encore une classe est la chose la plus importante dans le développement d’un projet.  

En effet, cela a de nombreux avantages comme : 

• Partager un même langage avec les experts métier et au sein de l’équipe de développement,
• Améliorer la clarté du code écrit,
• Répondre aux attentes du métier.

Coder sans designer 

Un code mal nommé est effectivement une source de problèmes qui peut conduire à un surcoût pour le projet. Mais ce n’est pas le seul problème qui peut subvenir, en effet, penser que développer sans designer est une économie de temps, l’est aussi ! 

Certes, l’effet n’est pas instantané, mais il sera forcément perceptible dans le temps, et cela sous différentes formes :

• code incompréhensible,
• maintenance complexe,
• débogage difficile,
• etc.

Cela induit forcément une perte de temps, un coût plus élevé et donc un time-to-market plus conséquent. Au début d’un projet, le modèle représenté dans le code est minimaliste, propre et compréhensible mais celui-ci prend vite de l’ampleur et fini par adopter l’effet “Big ball of mud” .

Une grande boule de boue est une vaste jungle de code mal structuré, programmé en spaghetti, peu soigné et souvent rafistolé. Ces systèmes témoignent clairement des traces d’une expansion incontrôlée, ainsi que de fréquentes réparations opportunes et improvisées. Les informations sont partagées sans distinction parmi les éléments distants du système, souvent jusqu’au point où presque toutes les informations importantes deviennent globales ou dupliquées. La structure du système dans son ensemble n’a peut-être jamais été bien définie. Si elle l’a été, le système a été tellement détérioré qu’il est impossible de la reconnaître. – Brian Foote et Joseph Yoder, Big Ball of Mud 

En réalité, ce modèle est constitué d’un ensemble de sous-modèles qui devraient être séparés, mais à la place, celui-ci réside dans un seul emplacement, voir même un seul namespace ou package. Chaque sous-modèle est censé former un ensemble cohérent et répondant à un comportement métier. Il est alors indispensable de comprendre la problématique métier, tout en collaborant avec les experts du domaine, et donc de designer une solution adéquate afin d’éviter les surcoûts et les problématiques de maintenance. 

CRUD et le modèle de données anémique 

 Si le seul outil que vous avez est un marteau, vous tendez à voir tout problème comme un clou – Abraham Maslow

C’est le cas lorsqu’une équipe de développement pense avoir la capacité de résoudre tout type de problème métier en utilisant une approche CRUD. Incitant ainsi à rendre le modèle de donnée anémique. Toute la logique et les règles métier peuvent s’éparpiller dans les différentes couches techniques, par exemple, dans la base de données ou l’interface utilisateur. Cela implique alors une maintenance longue et difficile.

Une mauvaise abstraction

Cela peut être un coût qui peut aussi augmenter quand l’équipe de développement essaye de rendre générique un modèle de donnée afin de faire face à des besoins métier fictif, non énoncés et peu probables.  

Rien n’est mieux qu’un exemple pour illustrer le coût émergeant d’une mauvaise abstraction . En effet, au lieu de créer un formulaire répondant aux besoins des experts métier, l’équipe de développement en crée un générateur. Entre autres, l’équipe envisage des évolutions futures sans avoir la garantie du gain. Ceci ne peut engendrer qu’une perte de temps pour le développement, plus de complexité et plus de maintenance en cas de « Bugs ». 

Comment faire face à ces problèmes ?

Changer la perception des experts métier et de leurs entreprises revient à se concentrer sur la problématique métier afin de livrer de la valeur. 

Par conséquent élever le niveau de maturité de l’équipe de développement, en vue d’acquérir cette finalité, est l’ultime démonstration d’une collaboration forte entre le monde métier et le monde technique. 

Des solutions métiers et non techniques

Garder le focus sur le besoin métier donne une impression aux experts métier que l’équipe de développement partage le même objectif. Leur présence est ainsi nécessaire pour collaborer ensemble afin d’apporter la meilleure solution à un problème métier défini.  

Dès lors, il faudra mettre en avant les solutions métiers et non pas les solutions techniques. 

Ce travail ne se résume pas uniquement au niveau du projet, de l’entreprise ou du département. Il se propage au niveau communautaire. Encourager des collègues à participer à des meetups, des conférences parlant de Domain Driven Design et de Software Craftsmanship ne pourra qu’être bénéfique pour chaque développeur car c’est en étant entouré de professionnels de la technique qui partagent la même vision de collaboration aide à s’aligner plus facilement.

Toutefois, élever le niveau de maturité nécessite des compétences humaines telles que l’éducation et la passion, qui, malheureusement, ne peuvent pas toujours être apprises.

Entretenir une collaboration forte

Une forte collaboration est synonyme d’une discussion, d’un atelier ou d’une pratique heuristique amenant un Craftsman à découvrir le monde fonctionnel. 

Notamment, faire sortir les experts de leurs bureaux et utiliser une salle pour discuter du métier est la meilleure solution pour collaborer et apprendre. 

Une communication face à face avec les experts du domaine métier, préconisant des scénarios et des exemples concrets, poussent les développeurs à oublier les Buzz Words et n’utiliser qu’un seul langage unique et commun (Ubiquitous Language), pourchassant ainsi le modèle amenant la solution métier vers quelque chose de plus bénéfique. 

Plusieurs techniques de workshop sont utilisées à cet effet, parmi lesquelles nous retrouvons :

• L’Event Storming: “Event storming is a flexible workshop format for collaborative exploration of complex business domains.”
  Durant cet atelier, l’équipe de développement utilise un langage commun avec les experts métier afin d’explorer le domaine, à travers des événements métiers. Ainsi, l’équipe de développement et les experts métier arrivent à recenser et bien définir le besoin et la solution à fournir. 

• L’Exemple Mapping, qui est une technique permettant de mettre en place des exemples concrets pour explorer les règles du domaine déjà identifiées au préalable. 

Un design réfléchi 

A l’issue de ces workshops, l’équipe de développement se retrouve avec plusieurs artefacts : 

• Une vision claire et globale du comportement métier.  

• Les sous domaines sont identifiés plus facilement. Les frontières se manifestent de façon naturelle durant ces ateliers. 

Une conception réfléchie de la solution devient alors plus facile à mettre en place. Les sous modèles déduits ne sont plus anémiques mais ils contiennent dès lors du comportement métier.  

De même, la logique métier n’est plus éparpillée dans la base de données ou dans l’interface utilisateur mais elle est recensée dans les sous modèles. 

L’équipe de développement fait face maintenant à des fonctionnalités métier à mettre en place, ne se souciant plus ainsi des évolutions futures « fictives » qui n’ont aucune garantie du gain. 

 La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. – Manifeste Agile

L’excellence technique

Plusieurs patterns d’architectures, notamment l’architecture hexagonale ou CQRS, permettent de nous focaliser et de sécuriser le périmètre fonctionnel du projet. Ces derniers aident aussi à éviter que la logique métier s’éparpille un peu partout dans la solution logicielle. 

Il y a aussi d’autres pratiques de l’ingénierie émergeant de l’XP (Extreme Programming) qui permettent une meilleure appréhension du métier et une meilleure maîtrise technique, tels que :par exemple l’intégration continue, le Pair Programming, TDD, Refactoring etc.

Conclusion

Le partage d’un même objectif, en se basant sur une collaboration forte, est synonyme d’un contrat de partenariat avec les experts métier. Afin de le respecter, plusieurs ingrédients doivent être évités et d’autres doivent être mis en place. Le langage doit être le même et l’excellence technique de développement doit être assurée.

Ces ingrédients amènent l’équipe de développement à s’engager sur une vision partagée avec les experts métier. Cela leur permet de partager un intérêt commun, celui de résoudre un problème métier à travers une solution fiable et un time-to-market concurrentiel tout en minimisant les coûts de maintenance. 

Ainsi, l’équipe de développement sera perçue comme un centre de profit et une partie prenante nécessaire à la réussite du projet, du département et de l’entreprise.