Ted Dziuba, programmeur et co-fondateur de Milo (comparateur de prix local), a écrit un article très intéressant fin octobre sur une méthode de programmation qu’il a intitulé « à la Taco Bell ». Comme nous n’avons pas de Taco Bell en France je l’ai traduit par McDo dans le titre!

Le concept?

The more I write code and design systems, the more I understand that many times, you can achieve the desired functionality simply with clever reconfigurations of the basic Unix tool set.

Ou en français (mon emphase en gras):

Plus je code, plus je réalise que la plupart du temps il est possible d’atteindre la fonctionnalité attendue avec une reconfiguration intelligente des commandes de bases d’Unix.

Avec un pas de recul, on peut appliquer cela à n’importe quel environnement de développement (la BI Microsoft par exemple), voir même à la méthodologie projet. C’est une attitude à contre pied complet de l’architecture interstellaire et pour l’avoir déjà mise en œuvre, qui donne de bons résultats.

Les principaux avantages sont la minimisation du risque et l’amélioration de la qualité du code par la maîtrise de bout en bout de toutes les fonctionnalités utilisées. Ted Dziuba le dit dans l’article : faire appel à des services tierce partie, des boîtes noires, c’est introduire du risque dans la solution.

Cette méthode amène de plus une réduction dans le choix de l’implémentation lors du design, et toute réduction de choix est bonne lorsqu’elle correspond à une réduction de l’effort nécessaire pour sortir de la procrastination et passer à l’action.

Le point négatif est évidemment le biais humain qui pousse au culte du cargo: ce qui est initialement une bonne pratique, un objectif, peut rapidement dégénérer en dogme et mettre en péril le projet. Il restera toujours un pourcentage de fonctionnalités qui nécessitent d’utiliser un service tiers spécifique, une technique spécifique, et vouloir les recoder dans les briques de base ne peut que conduire à une catastrophe (recoder un cube en TSQL – 300 tables d’agrégats à maintenir – ce n’est pas une bonne idée).

Un autre point négatif est qu’il faut disposer de collaborateurs capables de faire des reconfigurations intelligentes. Si l’intelligence manque en interne, autant s’appuyer sur l’intelligence qu’on peut trouver dans un service clef en main, tout le monde se sentira bien mieux.

Et par rapport à la gestion de projet, découper les périmètres complexes en briques élémentaires maîtrisées ça ne vous rappelle rien? La méthode agile oui, il me semblait bien 🙂