Illustration

Un article bilan questionne le développement informatique, son rapport à la simplicité, l’utilité et la multiplicité des méthodes, des processus qui veulent rationaliser, métrer, prévoir dans les moindres détails avant de faire [1].

Les développeurs au style cathédrale sont plus attachés à la méthode, à la forme du projet, aux outils et technologies qu’au résultat.

Les solutions issues du style cathédrale sont toujours complexes. Elles demandent des compétences profondes dans de multiples domaines pour comprendre, organiser, gérer le projet, le réaliser et le maintenir.

La surenchère fonctionnelle côtoie la surdivision des tâches et le surdimensionnement d’équipe - il en faut du monde. L’abstrait devient l’important et l’important devient le concret. L’administratif, le management, la gestion, la documentation, les analyses, les études, les procédures, les rapports, les réunions, les comptes-rendus, les contrats… deviennent l’important. Le projet devient visible, il se matérialise, mais pas dans son résultat, son but, sa raison d’être, non, il accouche de livrables, des avatars prenant la forme de documents normalisés.

Au bout d’un long et douloureux devenir, un livrable technique, un résultat émergera, digne héritier d’une solution complexe, massive et couteuse.

Ultime étape, la solution sera administrée par une organisation qui saura se rendre indispensable tout en se protégeant d’un manteau d’opacité que seuls quelques initiés pourront pénétrer. En observateurs, ils découvriront, peut être avec stupéfaction, qu’au final le projet, sous couvert de rationalisation, est articulé autour de certaines décisions péremptoires, totalement arbitraires voir irrationnelles - car il faut bien que quelqu’un décide.

A l’opposé, des développeurs au style hacker. Agiles, créatifs [2], centrés sur les individus et la résolution de leurs problèmes. En une fraction du temps nécessaire pour définir les contours du projet de type cathédrale, ils auront réalisé quelque chose d’opérationnel [3], installé les outils et l’environnement nécessaire puis partagé leurs expériences dans un wiki. Le résultat répondra à la demande, il s’affinera, s’améliorera avec le temps [4], par l’usage.

  1. http://su-shee.tumblr.com/post/50901053095/a-constant-source-of-confusion-simplicity
  2. https://larlet.fr/david/blog/2013/developpeurs-creatifs/
  3. http://fr.wikipedia.org/wiki/Principe_KISS
  4. https://fr.wikipedia.org/wiki/Loi_de_Gall