On le sait, “le gras c’est la vie”. Mais trop de gras sur notre corps peut être disgracieux. Dans une telle situation, on a souvent recours à un régime.
Et l’application sur laquelle vous travaillez ? A-t-elle quelques fonctionnalités superflues ? Devez-vous la faire maigrir un peu ?
Pour le savoir, calculez son Indice de Masse Grasse (IMG).

Vous êtes vous déjà trouvé dans le rayon d’un supermarché, bloqué face à un choix de produits trop vaste ? Vous vouliez, admettons, de la lessive. Et là, vous avez le choix entre 10 marques différentes, chacune proposant 5 parfums déclinés dans des gammes “classique”, “hypoallergénique”, “douceur”, etc. Bref, trop de choix tue le choix.
Ce principe s’applique aussi aux fonctionnalités des applications que vous développez. On pense qu’un vaste choix est une bonne chose et on en arrive à multiplier le nombre de features de façon déraisonnable. Ce faisant, on nuit à l’utilisateur qui ne saura plus quoi utiliser. On parle de Feature Creep. Ce phénomène est responsable d’une augmentation de la dette technique, du coût de maintenance, etc.
Oui, votre application doit faire un régime car, pour le moment, il faut dépenser trop d’énergie pour la faire bouger. Il y a trop de fonctionnalités superflues.
Pour nous aider, Stavros Stavru a imaginé un modèle permettant de calculer l’IMG de nos applications, qu’il a nommé The Fatware Matrix.

Présentation du modèle

Le modèle se présente sous la forme d’un tableau qui contient deux informations essentielles :

• Le coût de maintenance des fonctionnalités. Ce coût est représenté par des valeurs allant de 1 à 3.

• L’intérêt et l’utilité desdites fonctionnalités pour le client. Cela est représenté par la couleur et le type de tissus : rouge pour la Graisse (G), jaune pour les Os (O), vert pour les Muscles (M).

On classe ensuite les fonctionnalités de l’application étudiée selon ce modèle. Par exemple, une fonctionnalité indispensable pour client et au coût de maintenance élevé sera classée dans les os de type O3.
Connaître la répartition des fonctionnalités dans ce tableau va nous permettre de calculer l’IMG de l’application.

Calcul de l’IMG

1. Compter le nombre de fonctionnalités par cadrant
2. Multiplier par le coût de maintenance
3. Faire le total de chaque ligne
4. Diviser chaque résultat par le nombre total de fonctionnalités, pour en déduire le pourcentage de chaque type de tissus au sein de l’application

L’IMG de cette application est donc de 32%. Dans quel somatotype se situe-t-elle ?

Endomorphe, Ectomorphe ou Mésomorphe ?

Par analogie avec les somatotypes, Stavros Stavru définit trois types d’application.

• Le premier est appelé Endomorphe (Stavros parle de Fatware). Les applications de ce type sont caractérisées par une trop forte présence de la masse graisseuse et par un système musculaire sous-développé. Il faut dépenser beaucoup d’énergie (en termes de temps et d’efforts) pour les maintenir et les faire évoluer.
• Le deuxième type est appelé Ectomorphe (Stavros parle de Boneware). Généralement, de telles applications sont très minces. Elles ont beaucoup d’os mais peu de muscles. Cela risque de les rendre moins attractives pour le client et leur santé sur le long terme peut être en péril (je rappelle qu’on parle d’application, hein !).
• Le troisième et dernier type est appelé Mésomorphe (Stavros parle de Muscleware). Les applications possédant une large quantité de muscles et d’os se rangent dans cette catégorie. Elles sont bien équipées pour affronter le marché dans de bonnes conditions.

Bien entendu, des types intermédiaires sont envisageables.

Régimes et exercices

L’idée est maintenant de savoir quel type de fonctionnalité on doit s’interdire d’ajouter (oui, oui, on parle de régime), quels types développer et quels types améliorer (rendre moins coûteux à maintenir).
Par exemple, pour une application endomorphe, il est clair qu’on va s’interdire les fonctionnalités de type graisse (G1, G2 et G3). On va même faire des exercices pour en perdre certaines qu’on a déjà acquises.
De plus, comme on ne peut pas empêcher l’ajout de fonctionnalités, il va falloir favoriser l’acquisition de muscles (features de type M1 ou M2 de préférence). Là encore, cela passe par des exercices.

Cette gymnastique, vous la connaissez, on en parle régulièrement sur le blog : qu’il s’agisse de refactoring ou de méthodologie d’écriture de code, vous avez tous les outils en main !

Crédits

Ce modèle a été imaginé par Stavros Stavru. Il le décrit en détail dans un article intitulé The Fatware Matrix.