Ne laissez pas le chaos l'emporter

Soyons franc, on n'apprécie pas beaucoup le désordre même s'il faut vivre avec. Dans un monde idéal, on combat férocement le chaos que peuvent créer les Kim Jong-il, Darth Vader ou Sauron. Seulement parce que l'équilibre de la paix est fragile et que les conséquences peuvent s'avérer désastreuses.

Tout comme en programmation. Elle se doit d'être structurée, hiérarchisée, reglementée pour que tout tourne rondement. En cours de développement, l'utopie est de construire le tout dans les règles de l'art. La réalité ressemble davantage à de la rénovation ou à une réparation de voiture : on droit tricher d'un peu partout, forcer les pièces du puzzle ensemble pour qu'elles finissement à s'emboîter adéquatement.

Lorsqu'un client soumet une demande de changement, il voudra l'obtenir au meilleur prix, même s'il faut le corriger avec du mastic et du ruban adhésif. Aux yeux de la majorité, ce genre de dépense ne procure aucun plaisir en retour alors pourquoi payer plus ? Et c'est généralement là que ça se met à déraper. Comment justifier le prix d'une réparation faite correctement si une patch à moindre coût peut suffire ? En tant que développeur, on peut tolérer quelques patches mais il vient un temps où il faut cesser de remettre du ruban adhésif par-dessus l'ancien qui déchire sans cesse.

Dans le meilleur des mondes, un logiciel serait construit comme un gratte-ciel. La fondation doit être suffisamment inébranlable pour y empiler de multiples étages de dimensions égales qui pourront à leur tour accueillir des étages supplémentaires au sommet afin de répondre aux demandes futures du client. Les contraites du monde réel font que les logiciels sont plus souvent bâtis comme une pyramide. Un nouvel étage trop large juché au sommet risque tôt ou tard de devoir tenir en équilibre sur la pointe, jusqu'à ce qu'il bascule dans le vide au moindre coup de vent. D'autres fois, la demande sera de venir glisser un nouvel étage entre le 7ème et le 8ème plancher d'un building existant (essayez un instant de vous représenter une image mentale de ce que ça implique). Retirer le 13ème étage malchanceux ? Aussi simple que de tirer une briquette d'un jeu de Jenga! Dans tous les cas, effectuer le travail proprement, tout en minimisant les risques pour les travailleurs, fera grimper les coûts liés de rénovation et de logistique de construction. Et dans certains cas, le danger est tellement grand qu'il serait peut-être plus sage de refuser le mandat plutôt que d'accepter les pires conditions et la responsabilité en cas de désastre.

Quand on parle de chaos, il faut aussi savoir reconnaître les signes précoces avant que ça commence à dégénérer. Prenez par exemple une usine. Pendant tout le temps qu'elle est en fonction, ses occupants en prennent soin (du moins, ils sont supposés). Le jour où le propriétaire met la clé sous la porte et que le bâtiment est abandonné, s'il n'est pas surveillé, ce ne sera qu'une question de temps avant qu'il commence à être vandalisé. Une fenêtre pourrait être brisée. Si elle n'est pas réparée rapidement, elle deviendra une cible facile : d'autres vitres seront fracassées, des graffitis feront leur apparition, des itinérants et des squateurs s'y établiront, ils commenceront à salir leur environnement emprunté, des dommages structureux gravent apparaîtront. Dans un espace de temps relativement court, le bâtiment sera endommagé au-delà de la volonté du propriétaire de la réparer, et le sentiment d'abandon deviendra réalité.

Lorsque le désordre augmente dans un logiciel, les programmeurs parlent alors de pourriture. Dans le livre The Pragmatic Programmer, From Journeyman to Master, les auteurs citent ce genre d'histoire pour nous rappeler une règle importante à retenir : ne laissez jamais une fenêtre brisée (mauvais design, mauvaises décisions, mauvais code) non réparée. Fixer le tout correctement dès que le problème est découvert. Prenez des mesures pour prévenir d'autres dommages. La négligence ne fera que détériorer le système rapidement.

C'est une question de gros bon sens. Maintenant, le défi est d'essayer de le faire comprendre au client...

Tags: Lois et principes, Programmation