Suite à mon article intitulé L’élégance du logiciel, un de mes lecteurs m’écrit : « Mais ne risque-t-on pas de finir par faire l’amalgame entre obésité et laideur ? ». À mon avis, il ne faudrait pas confondre les deux.

Comme vous pouvez le voir sur la photo, on peut être obèse et très beau ! CQFD.

D’ailleurs, dans mon article, je ne parlais pas tant de « beauté » que d’ « élégance » du logiciel. Élégant étant défini comme « gracieux dans la simplicité » ou « sobre et de bon goût ».

Mais revenons à l’obésité, qui est un vrai problème en informatique.

Quelles sont les causes de l’obésité fonctionnelle ? Une tendance à la facilité et à la surconsommation. Les mégaoctets sont de moins en moins chers, le temps de calcul aussi. Il est plus facile de pondre des lignes de code que de penser un algorithme. Il est plus facile d’accumuler les pages de spécifications détaillées que de prioriser les besoins. Remplacer la qualité par la quantité, c’est la solution de facilité Du coup, toute l’industrie du numérique souffre d’une fuite en avant.

On pourrait imaginer que l’obésité fonctionnelle ne pose pas de problème sur le plan de la qualité, de la valeur du logiciel. Si la mémoire et la puissance machine ne coûtent pas cher, pourquoi s’en priver ? mais le problème n’est pas là. Il ne s’agit pas de s’en priver, il s’agit au contraire de l’utiliser judicieusement. Compenser une « mauvaise programmation » par une consommation excessive de ressources est une erreur classique des étudiants en programmation. Mais si vous programmez mal, le moment arrivera où l’augmentation de la ressources ne compensera pas l’augmentation des besoins de ressources. Il y a une manière élégante de programmer, et c’est aussi la plus efficace.

L’obésité fonctionnelle

Ce qui est valable pour la programmation l’est également pour la construction du logiciel dans son ensemble. Prenons un exemple bien connu : d’une version à l’autre, les logiciels de bureautique occupent une place de plus en plus importante sur le disque dur. Cela pourrait être sans conséquences. La capacité des disques durs et des clés USB n’est-elle pas de plus en plus importante, pour un prix et un poids de plus en plus faible ? cependant le problème n’est pas dans la capacité mémoire. Il est dans l’utilité des fonctions offertes par le logiciel, et par leur utilisabilité.

Pour nous en convaincre, essayons de mettre chaque fonction offerte par un logiciel dans une (ou plusieurs) des catégories suivantes :

– FEU : fonctions effectivement utilisées, par au moins 20 % des utilisateurs,

– FFU : fonctions fréquemment utilisées, par 80 % des utilisateurs ou plus,

– FPU : fonctions potentiellement utiles, qui seraient utilisées si elles étaient mieux documentées qu’elles ne le sont aujourd’hui ;

– FDE : fonctions déficientes : incorrectement documentées, ou inutilisables car elles font prendre des risques aux utilisateurs, ou leur font perdre plus de temps qu’elles ne leur en font gagner ;

– FO : fonctions obsolètes : utiles dans les versions précédentes, et devenues inutiles du fait de l’arrivée de nouvelles fonctions,

– FR : fonctions redondantes, que l’on peut trouver sous d’autres formes dans l’application, ou dans une autre application,

– FDI : fonctions dissimulées, à la fois non documentées et inutiles,

– FM : fonctions mortes, c’est à dire existantes, défaillantes ou non, mais enfouies dans le logiciel et inaccessibles à l’utilisateur.

Lorsque le nombre total de fonctions est très largement supérieur au nombre de fonctions utiles, on pourra dire que le logiciel est obèse.

L’inélégance, c’est autre chose. On peut la mesurer en faisant le rapport entre la complexité (par exemple le nombre cyclomatique selon McCabe) et la taille fonctionnelle (en points de fonctions). Ou entre la richesse d’une fonction et la difficulté d’y accéder.

Le problème de l’obésité n’est pas tant la mémoire occupée que la difficulté à gérer l’ensemble :

– les fonctions obsolètes ou redondantes trompent ou perturbent l’utilisateur,

– les fonctions mortes rendent la maintenance du logiciel difficile,

– les fonctions déficientes posent souvent des problèmes de fiabilité ou de sécurité.

Autres formes d’obésité

Chaque fois que l’on en fait « plus » au lieu de faire « mieux », la qualité en pâtit. En informatique, on peut citer diverses formes d’obésité :

– la surabondance de la documentation utilisateur, et qui la rend totalement inutilisable,

– la surabondance de documents méthodologiques à l’usage des développeurs, que personne ne pourra lire avec attention,

– la tendance, tant de fois décriée, à augmenter la taille des équipes lorsqu’un projet de développement prend du retard, avec l’effet exactement inverse à celui escompté,

– et dans le domaine que je connais bien, l’ingénierie des exigences, la tendance à multiplier les groupes de travail et le nombre de participants à chaque groupes là où un seul atelier bien mené aurait été suffisant.

Comment éviter ou limiter l’obésité

De même qu’il n’y a pas régime amaigrissant miracle, il n’y a pas de méthode miracle pour combattre l’obésité du logiciel. Il y a des bonnes pratiques, et elles sont connues depuis longtemps :

– Donner toute son importance à la phase amont de la construction du logiciel. Que vous l’appeliez Analyse préliminaire, définition des objectifs, Vision and Scope ou schéma directeur, cette phase amont est cruciale. Ceux qui ont lu mes livres et suivi mes formations savent qu’il y a trois choses à connaître et à formaliser préalablement au recueil des besoins : L’objectif, le périmètre et les parties prenantes.

– Faire une véritable analyse des besoins, et y mettre les moyens, sachant qu’un franc investi dans l’analyse des besoins, c’est cent francs d’économisés sur le coût de fonctionnement, les statistiques sont très claires.

– Lors de l’analyse des besoins, détecter les véritables besoins, et en particulier analyser et prioriser les « besoins verticaux », ils sont très souvent source de fonctions inutiles (voir à ce sujet mon article intitulé Timex contre Rolex).

– Travailler selon une démarche itérative, incrémentale, agile, appelez-la comme vous voudrez, et oublier les « cathédrales logicielles ».

– En phase de maintenance, éliminer les fonctions obsolètes et faire la chasse au « code mort », c’est-à-dire aux bouts de programme qui ne servent à rien.

– enfin, cesser de récompenser la quantité au détriment de la qualité, comme cela se fait encore. Il est toujours préférable de livrer 80 % des fonctions demandées (souvent à 20% du coût total), plutôt que 100 % de fonctions inadéquates, inutilisables ou déficientes.

Ces principes sont connus depuis longtemps. Reste à les mettre en œuvre !

© Yves Constantinidis, 2022