il y a 4 hour
2
L’estimation du temps et de la charge est un sujet crucial dans le développement logiciel. Elle détermine le budget et le planning. La vérité est triste hélas : qu’on se place dans les années 1970 des ordinateurs centraux IBM ou dans le cloud de 2026, il est difficile d’estimer précisément le travail nécessaire pour créer un logiciel non trivial. Impossible, diront certains.
Des ouvrages entiers ont été écrits sur le sujet. Certains pensent qu’il est plus sage de ne pas communiquer d’estimation : le logiciel sera prêt quand il sera prêt. Tom DeMarco, informaticien et auteur, a proposé de jolies formules : une estimation est la prévision la plus optimiste qui présente une probabilité non nulle de se réaliser, ou encore, la date la plus proche à laquelle on ne peut pas prouver que le travail ne sera pas terminé. De manière pratique, une estimation est surtout un chiffre imprudent, mais consciencieusement noté dans un tableur, que la hiérarchie exhumera demain pour constater un retard inadmissible.
Concevoir un logiciel, n’importe lequel, c’est rarement refaire quelque chose. C’est davantage imaginer une façon d’utiliser des outils, un savoir-faire, une expérience pour faire quelque chose de nouveau. Il ne suffit pas de brancher un agent d’aide au développement. Programmer relève à la fois de l’art et de la technique, de l’artisanat (craft) et de l’ingénierie.
Pour créer un programme, il faut l’écrire. Pour l’écrire, il faut le concevoir. Pour le concevoir, il faut savoir très précisément ce qu’il doit faire, jusqu’à aboutir au niveau le plus bas de détail : le code source. Un programme n’est qu’une suite de décisions de plus en plus détaillées. Chaque cas est unique, donc chaque programme sera unique. Et parce que vous ne savez pas quels cas devront être traités et quelles décisions devront être prises avant de les prendre, l’incertitude sur le travail nécessaire subsiste jusqu’à la fin.
Loi de Hofstdater : « Il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter. »
L’informaticien est un être social qui écoute, reformule, synthétise et explique. Il faut révéler le besoin. La « dev’ » doit écouter et d’une certaine façon entrer dans la tête de son interlocuteur. Puis se concentrer sur les problèmes à résoudre, s’immerger et plonger en profondeur.
Prenons une fonctionnalité : ajouter un bouton sur une interface graphique, créer un profil utilisateur, améliorer un filtre graphique, chercher un motif statistique dans des signaux expérimentaux ou intégrer une source de données dans le processus d’entraînement d’un programme d’IA. La data scientist aura parfois la chance de s’aventurer dans des bases de données inconnues, massives et uniques, ou d’utiliser des outils spécifiques issus de la recherche.
Voici les questions qui cascadent sur le développeur. Cette fonctionnalité est-elle critique ? A-t-il compris ce que l’utilisateur attend ? Celui-ci le sait-il lui-même ? Peut-on choisir une version simple, plutôt rapide à implémenter, ou doit-on s’embarquer dans la complexité ? Quelles futures évolutions peut-on anticiper ? Quelle couverture de tests ? Le nouveau code s’intègre-t-il aisément dans la base existante ? Et enfin, l’éternelle question : combien de temps vais-je devoir consacrer à chasser les bugs que j’aurai moi-même écrits ? Ces questions conditionnent directement le temps de développement. Les facteurs multiplicatifs s’accumulent. Entre une fonctionnalité simple implémentée rapidement, et la version plus complète, avec une bonne couverture de tests, le temps de développement peut bondir d’un facteur 10, voire plus. Et on ne parle pas des différents niveaux de complexité algorithmique, critique quand les ressources sont limitées ou si un niveau de performance doit être garanti.
Tentons une métaphore. Concevoir un programme, c’est établir la carte d’un territoire inconnu. Ce territoire représente l’ensemble des contraintes qui définissent le futur logiciel. Il y a différentes façons d’établir la carte. On peut observer le territoire avec des satellites et des avions de reconnaissance pour certaines zones. L’équipe de développement analysera ensuite l’ensemble des informations avec les futurs utilisateurs, afin de lister précisément ce qu’ils veulent faire et ce qu’ils attendent. En creux, il s’agira d’identifier ce qui reste flou, absent ou contradictoire. Et de circonscrire au mieux les terribles « UU » (unknown unknowns), ce qu’on ignore ignorer.
Parfois les avions d’observations ne décollent pas, ou le brouillard ne se lève pas. Alors on enfile ses bottes et on part sur le terrain, avec son git (forge logicielle, construite à partir du logiciel « git ») et son clavier. Il faut garder en tête que la carte n’est pas le territoire. Le développeur n’est nullement à l’abri, en cours de route, de découvrir que telle route n’est pas praticable ou qu’il y a là un terrible fossé : les attentes des clients étaient incomplètes, mal exprimées voire inconnues, telle fonctionnalité doit être ajoutée, etc. L’impact de ces modifications sur le projet et sur la base de code peut être négligeable ou dramatique. Impossible de s’en prémunir. Impossible de tout anticiper. Dans le monde du développement logiciel, les imprévus font partie du jeu. Les devs n’attendent pas que les orages passent, ils apprennent à danser sous la pluie.
