‘Ecrire du code, c’est bien autre chose que de construire des ponts’

La semaine dernière, Rudolf de Schipper se plaignait du fait que les développeurs de logiciels fournissent trop souvent un travail sans garantie qu’il s’agisse d’un produit impeccable. Il ajoutait qu’ils ne méritaient donc pas l’appellation ‘ingénieurs’. Le développeur de logiciels (et ingénieur) Kris Peeters lui répond.

Le 20 juillet, Rudolf de Schipper, Senior Project Manager chez Unisys, écrivait ces mots: “De mémoire d’homme, le développement de logiciels est aux prises avec les mêmes symptômes: trajets longs et complexes, et il en va de même pour le code. Il en résulte que le résultat final contient encore de nombreux bugs et s’avère toujours plus coûteux que prévu”. Et de qualifier les développeurs de logiciels actuels ‘d’amateurs’, qui ne méritent pas l’appellation ‘d’ingénieur’.

Je peux parfaitement m’imaginer d’où provient cette frustration débordante. Elle semble émaner de quelqu’un qui a dirigé des années durant de vastes projets software. Ceux-ci adoptent toujours le même modèle: un méga-accord de quelques millions d’euros est signé, en vue de remplacer complètement un ancien système. Comme il s’agit d’un projet pluriannuel, on y consacre dans une première phase une dizaine d’analystes business pour définir exactement ce dont le client a besoin. Lorsqu’ils ont terminé leur travail, ils cèdent la pace à des analystes techniques et à des architectes pour convertir très précisément les exigences du métier en besoins techniques et en une architecture IT globale capable de faire face à ces besoins. Car un professionnel ratisse large, avant de commencer. Dans la phase suivante, ce sont pas moins de dix développeurs de logiciels qui sont sollicités pour implémenter tous les besoins techniques en fonction de l’architecture IT spécifiée par les architectes. Nous évoluons évidemment avec notre temps et procédons donc de manière “agile”. Nous faisons alors appel à trois project managers pour introduire tous les besoins techniques dans un ‘backlog’. Il appartient ensuite à quatre ‘software teams’ de fournir le backlog, représentant vingt années de travail d’un homme, par de brefs rushs de deux semaines. Par souci d’exhaustivité, on recourt encore à un certified scrum master et à un agile coach. Ensuite, ce sont vingt testeurs qui entrent en scène pour tester tout manuellement. Ces testeurs se trouvent de préférence sur un autre continent, afin de réduire les coûts. Car nous sommes des managers expérimentés qui veillent à réduire autant que possible les frais. Pour terminer, tout est correctement inséré dans un vaste document Word et envoyé au département Operations, où le gigantesque projet IT peut enfin être mis en production au bout de trois années de labeur, afin que la ‘business value’ promise trois ans auparavant puisse être fournie. Mission accomplie. Par ici les millions. Place au prochain projet.

Petit problème: ce sont tous des mensonges que les grandes agences de consultance servent à leurs clients ignorants. Comme De Schipper l’écrit, ces projets sont en effet toujours fournis trop tard, trop chers et avec de nombreux bugs. C’est ainsi depuis des décennies. Et voilà pourquoi De Schipper se laisse aller et reproche à ces amateurs de développeurs de logiciels de ne pas fournir des produits impeccables.

Et bien cher Rudolf, tout ce qui est décrit ci-dessus, est le parfait exemple d’un échec de management et pas d’un échec d’ingénierie. Les ingénieurs savent depuis la sortie de l’agile manifesto, dont vous vous moquez, qu’il y a une meilleure façon de travailler. Et depuis le mouvement DevOps, on sait aussi qu’il y a des manières de fournir du code rapide et de haute qualité, l’un renforçant l’autre. Il a déjà été démontré plusieurs fois que nous pouvons fournir assez rapidement le produit voulu, si nous pouvons y incorporer la qualité de manière à la fois continue et disciplinée. Et je ne parle pas ici de ‘scrum’, mais de Test Driven Development, Continuous Integration, Continuous Deployment, Infrastructure as Code, cloud-native architectures, kubernetes clusters, micro-services,… Et nous ne signons pas des méga-contrats qui soient fixed price, fixed scope et fixed deadline. Au contraire, nous libérons un budget et définissons un objectif. Il appartient alors à l’équipe de développement, conjointement avec le métier, de se rapprocher de ce but par petites itérations. On appelle cela du lean management.

Agile, DevOps, lean,…: dans votre monde tous des termes inventés par des développeurs paresseux et par des hippies incapables de s’en tenir au schéma d’un projet. Dans le monde réel par contre, ils enregistrent des résultats étonnamment bons. Preuve en est par exemple l’engineering masterpiece de l’architecture Netflix. Netflix fait tourner en continu un Chaos Monkey dans ses systèmes de production. Ce Chaos Monkey interrompt aléatoirement des connexions, désactive aléatoirement des serveurs et perturbe des lignes de communication. Netflix continue ainsi de tourner de manière toujours stable, même s’il y a vraiment quelque chose qui cloche. Il ne nous faut cependant pas seulement aller voir en dehors de nos frontières nationales. Ici en Belgique, tant les startups que les grandes entreprises sont en train d’innover comme il se doit.

Non, l’orientation objet n’est pas le dernier grand changement dans l’IT. Les langages fonctionnels gagnent du terrain. Des services indépendants plus modestes deviennent importants. Les bases de données NoSQL prennent des parts de marché. Les ‘real-time streaming analytics frameworks’ gagnent en maturité,… et même les banques se mettent à accueillir à bras ouverts agile, DevOps et Lean. Ces entreprises disposent d’équipes trans-fonctionnelles disciplinées et de qualité et ciblent au minimum dix déploiement de code par jour.

Il faut que cela se sache: écrire du code, c’est bien autre chose que de construire des ponts. Le code est la meilleure abstraction dans le monde numérique. Le code, c’est le plan qui décrit la façon dont un pont doit être construit. Déployer le code et le mettre en production, c’est lancer un nouveau pont dans un environnement spécifique. Et nous construisons ainsi des centaines, voire des milliers de ponts par jour sur des serveurs qui peuvent se planter à tout moment, avec des connexions de réseau susceptibles de s’interrompre à chaque instant. Pourtant, les ponts continuent d’être construits automatiquement, afin que chaque Belge puisse se livrer à du banking mobile avec son smartphone, commander sa TV numérique, visiter son site d’actualité favori, passer ses commandes d’e-commerce, etc., etc.

Et cela, cher Rudolf, c’est un sacré tour de ‘top-software-engineering’, made in Belgium. Donc la prochaine fois que vous démarrerez encore un mégaprojet, un simple conseil: faites un pas de côté et laissez les ‘software engineers’ passionnés faire leur travail. Du moins, s’ils en restent encore chez vous…