La qualité d'un projet, cette boule à facette !

Dans les tréfonds du monde, depuis la nuit des temps, deux forces s’affrontent dans un combat acharné. Deux puissances, deux armées, deux doctrines, deux visions du monde. Qui que vous soyez, vous êtes confronté(e)s chaque jour à cette guerre sans fin. D’un côté, les fervents défenseurs de la précision, les apôtres du parfait : les perfectionnistes. En face, les partisans de l'efficacité et des décisions rapides : les pragmatiques. Sonnons le tocsin, rassemblez-vous, hissez le drapeau blanc, il est l'heure des pourparler !

Voir la vérité en face pour alimenter une réflexion saine

Depuis des années, plongé au cœur des équipes de développement, j'ai découvert cette confrontation silencieuse et presque invisible, qui oppose deux visions très différentes du développement informatique. Une sorte de tiraillement constant chez les développeurs mêlés de compromis : jusqu’où aller dans la qualité du code produit ?

Cet article ne sera peut-être pas consensuel et va surement irriter de nombreux lecteurs, mais j'espère toutefois apporter assez d'éléments pour alimenter une réflexion sereine autour de ce sujet délicat.

Un monde qui change, des développements qui changent

Ces dernières années, le développement à changé d’ère ! Plus que jamais au cœur de nos sociétés, la conception de logiciel, de sites web est devenue essentiel au collectif.

En conséquence, la communauté de développeurs s'est rangée en ordre de bataille, accélérant les cycles de développement des technologies, proposant de nouveaux langages, de nouvelles méthodes de développement et des standards. Jamais il n'y eut autant de développeurs dans le monde, jamais ils n'ont été aussi indispensables qu’aujourd’hui.

Ce point est encore plus perceptible lors de la crise covid-19 où chacun est resté chez soi en s'appuyant sur des solutions en ligne (conf call, tchat, cours en ligne, déclaration administrative, livraison à domicile..). Toute une société, toute une économie, un monde qui reposent sur des plateformes numériques.

L’attente est donc forte, l’exigence technique aussi. Ainsi, pour une entreprise du secteur, pour les équipes de développement, les choix techniques opérés sont cruciaux et demandent un vrai recul sur les technologies et les méthodes à intégrer.

Cela fait des années que je voulais écrire sur le sujet mais j'étais face à un mur, incapable de dérouler correctement le fil de ma pensée. Trouver les bons mots, équilibrer les arguments, quel casse-tête !

Je voulais à l'époque, pour traiter de ce thème, confronter pragmatisme et perfectionnisme. Mes supposés Yin et Yang. Or, comme toute chose dans la vie, la vérité est plus nuancée. J’ai donc revu ma copie.

Négliger l’analyse technique initiale

Dans beaucoup de métiers, on pourrait croire qu'il est facile de déterminer si le travail est fait ou pas. Ma voiture est passée chez le mécano : ll l’a réparée ou non. Je vais chez l’ostéopathe : il m'a débloqué le dos ou non. Ici, on pourrait penser que la réponse est binaire.

Un mur en parpaing se construit d'une seule façon, un chirurgien respecte un protocole pour une opération donnée. Il n'y a pas beaucoup de place à la prise d’initiative et l’on connait l’ensemble des conditions pour réussir ce que l’on a entrepris.

Pour un projet informatique, même si l’objectif est connu (et encore), les moyens pour y arriver divergent : quelle technologie utiliser ? Comment sera découpé le projet ? Où sera-t-il hébergé ? Quelle architecture de base de données ? ... autant de questions, autant de réponses différentes.

Alors oui, il y a des bonnes pratiques, des façons de faire, des guidelines (même si elles peuvent se contredire et que, dans tous les cas, elles ne sont pas une réponse immédiate à une problématique donnée). La responsabilité est donc sur les épaules des développeurs et leurs choix techniques seront irrémédiables.

Les conséquences d'une mauvaise décision sont multiples : par exemple, des fonctionnalités bridées par le peu d'évolutivité du langage, un projet moins performant qu’espéré, des incompatibilités à l’utilisation, une obsolescence accélérée par des technologies immatures ou pire, une instabilité globale par manque de connaissance de l'équipe. Il y a des dizaines de raisons pour planter techniquement un projet.

J'avais écrit il y a quelques temps un article sur la dette technique qui parlait principalement de l'obsolescence et du fait de ne pas prévoir de la mise à jour dans les cycles de développement. Ici, j’évoquerai une dette plus insidieuse, celle que l’on se créer volontairement.

Utiliser des technologies inadaptées

Évidemment, comme tout ego qui se respecte, chaque développeur pense faire les bons choix. Dans cette logique, nous pensons que notre projet a une dette quasi nulle en début de cycle de vie.

Malheureusement, c'est tout le temps faux car nous manquons d'objectivité. nous sommes arc-boutés sur nos habitudes, nos lubies, nos réflexes de développeurs et calquons d'une manière automatique nos solutions favorites sans prendre de recul. Cet automatisme est naturel mais générateur de lacunes techniques.

Comment choisir la bonne techno https://www.commitstrip.com/fr/2015/09/16/how-to-choose-the-right-javascript-framework/

Ce fonctionnement-là n'est plus possible. Ce n'est pas parce que vous faites du Delphi depuis 10 ans que le delphi pourra réaliser tous les projets de vos clients. Inversement, ce super framework JS sorti récemment n'est surement pas la réponse à apporter à votre client qui recherche de la solidité. Il n'est plus possible de faire le choix d'une technologie sur des affinités ou des projections personnelles.

Un développeur doit avoir le recul et une connaissance périphérique des technologies suffisante pour prendre ce type de décision. Dans tous les cas, le choix doit être collégial.

Accepter des projets sans discernement

Au niveau décisionnel, la responsabilité est forte. Recueillir l'avis des équipes et identifier ses forces et ses faiblesses permettent d'avoir une vision claire des projets que vous êtes capables de gérer. Même si dire non à un de vos clients parait contre nature, il est pour ma part l'indicateur d'un grand professionnalisme et d'une honnêté plus que nécessaire aujourd’hui.

La sur qualité qui empêche d'avancer

Nous manquons souvent de discernement car nous sommes avant tout des amoureux du code. Ce que nous développons représente une part de nous. Nous avons donc un attachement tout particulier à chaque ligne produite.

Dans le cas d'un refactoring par exemple, il faut toujours réfléchir à l'objectif final. Si vous le faites pour la beauté, pour le style, vous êtes peut-être dans l'erreur. Quand vous travaillez dans ces buts, vous travaillez pour vos pairs, pour vous (pour votre ego ?) mais peut-être pas pour le bien absolu du projet (et donc des utilisateurs finaux).

Pour eux, l'important, c'est que le site, l'application qu'ils utilisent délivre le service promis. Cela peut-être de la rapidité, de l'évolutivité, cela peut être de la stabilité, cela peut-être tout autre chose mais votre refactoring servira-t-il cet objectif ? Si ça se trouve, l'objectif du projet n'est peut-être même pas d'être évolutif... La valeur ajoutée se trouve donc plus dans la forme que dans le fond et c'est cela qui fait que votre projet sera un succès.

L'over engineering expliqué aux enfantshttps://medium.com/@akashdas_37069/over-architecting-3b0296da41de

La surqualité et la surconception peuvent plomber un projet et freiner sa création de valeur. Aussi beau soit-il, un projet en retard et surtout sans les fonctionnalités essentielles aux utilisateurs sera un échec !

^ De mon avis, il faut moduler sa rigueur de développement en fonction des priorités fonctionnelles. On bétonne là ou c'est nécessaire et on peut laisser en friche les parties moins exigeantes. Il faut dépenser son énergie intelligemment.

Se tromper de priorité

Je trouve qu'il est important de connaitre dès le début les grandes priorités d'un projet. Par exemple, on ne mène pas les développements de la même façon si la rapidité est un enjeu au détriment de la pérennité.

Prenons l'exemple d'un site web avec une grosse volumétrie et un trafic conséquent. Ici, la question des performances est importante et doit être un sujet d'attention. Si votre base de données est mal conçue, si vos requêtes ne sont pas optimisées, vous le payerez cash. Ce sont ces éléments de base qui détermineront la qualité d’ensemble, pas la version de votre framework !

Concevoir étape par étape https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

Tout cela est donc à géométrie variable et mérite d'être un minimum analysé en amont. C'est avant tout une discussion à avoir avec votre client pour le confronter à ces dilemmes.

Je fais quoi alors ?

Revenir à l'essentiel : le besoin

Il faut revenir à la raison, au sens de ce que l'on fait et pour qui on le fait. La technologie est un moyen de réaliser des choses, pas un but en soit. Nous avons la chance d'avoir des outils et des guides pour structurer nos développements alors n'oublions pas qu'ils sont au service de votre projet. En aucun cas, ils doivent être un frein à l’efficience.

Arrêtons de tout jeter à chaque projet et de renverser la table sous prétexte de lacunes techniques. Arrêtons de faire rentrer de force au chausse-pied des projets dans des solutions mal adaptées. Il est très compliqué d'identifier le véritable besoin par la simple expression de son client ou des utilisateurs.

Pour se faciliter la vie, on peut puiser dans les nombreuses méthodologies de conduite de projet tel que le QQOQCCP (Quoi, Qui, Où, Quand, Comment, Combien, Pourquoi) ou encore du Lean. Cette efficacité passe donc par la conception de projets ajustés, sans gras et avec la bonne échelle de qualité.

Les projets ne se financent pas seuls

Dans la balance de vos choix, n'oublions pas le facteur économique qui détermine souvent la réussite du projet. Comme dans beaucoup de secteurs, l'équilibre entre coût de développement/fabrication et la qualité sont complexes.

Pour un client, ces aspects sont troubles, c’est une boite noire. Il paye, suit le projet mais ne peut évaluer la qualité réelle de ce qui est réalisé. Il s'appuie uniquement sur son utilisation, son ressenti et surtout les échanges avec les équipes. La confiance, la transparence doit permettre à chacun de se comprendre.

Un projet réussi est avant tout celui qui satisfait ses utilisateurs.

Ni pragmatisme, ni perfectionnisme : du réalisme

Tout est question d'adaptation au contexte. Dans tous les cas, restez ouvert d'esprit, remettez-vous en question et mettez-vous à la place des utilisateurs. C'est la meilleure façon d'éviter de foncer dans une impasse que l'on s'est construite seul.

Les prochaines années verront accélérer cette mutation des entreprises vers encore plus de solutions numériques. Ce n'est plus optionnel, c'est obligatoire. C'est maintenant à chaque acteur de la chaîne de développement d'être vigilant, de conseiller ses clients et de concevoir des projets efficients. Des conditions nécessaires pour que l'avenir du numérique ne soit pas une constellation de projets inadaptés.

Nous avons l'habitude, de notre œil de développeur, de juger la perfection d'un projet par "la qualité de notre code". Au final, la perfection ne serait-elle pas de répondre au besoin de la façon la plus adaptée ? Enfin, ce qui est valable pour un projet l'est aussi au niveau de l'entreprise qui doit lutter contre sa nature à rajouter des process dans son fonctionnement...mais c'est un autre sujet :)