Création logiciel, Hiérarchie et libre-arbitre

En réaction au post précédent Nous sommes tous des Architectes, j’ai reçu un commentaire sur LinkedIn qui disait cela:

<< Sébastien L. : Il y a un temps pour tout et une autorité pour tout. Le libre arbitre n’est pas possible dans une chaine hiérarchique car celle-ci serait rompue. La hiérarchie porte les responsabilités et décide. Il en est ainsi. >>

J’avais commencé de faire une réponse puis mon browser s’est fermé suite à une mauvaise manip et j’ai perdu mon texte. Voici la synthèse mieux écrite…

En matière de construction logiciel moderne, la notion d’autorité au sens primaire avec responsabilité et décision et relation maître-esclave n’existe pas. Construire un logiciel, c’est un travail d’ingénierie collaboratif. Ce n’est pas un travail à la tâche avec un patron et des ouvriers presse-boutons. L’armée ne sait pas faire et ne saura jamais faire un grand logiciel. Un logiciel est une construction de l’esprit fait par un ou plusieurs individus de manière collaborative. Cela peut être créatif ou scientifique mais cela reste un art. Le coup du “y a une chaîne hiérarchique qui porte responsabilités et décide !” est représentatif du système français et des SSII… Ce modèle est stupide. Avec cela, on fait de mauvais logiciels, sans qualité et sans âme que personne en veut utiliser… Les développeurs quittent le navire, le travail est médiocre et on tombe dans la caricature.

Un logiciel moderne, c’est une construction en légo. Il y a des centaines de briques. La responsabilité de la construction logicielle appartient aux Architectes et à eux seuls. Les design et le codage des briques est le domaine de développeurs. Comme vous le savez, un développeur est aussi un architecte.

Chaque développeur est autonome via:

  • sa capacité à designer les composants
  • sa manière d’implémenter les composants
  • sa vision de l’utilisation des composants qu’il veut donner

Ce n’est pas une personne qui possède le titre de chef de projet qui va expliquer au développeur comment il doit procéder, sur combien de temps, etc. Dans le monde du développement logiciel moderne, le terme de chef de projet n’existe plus ! Il a des gens qui coordonnent les réunions, s’occupe du planning mais n’ont aucune responsabilité dans l’architecture et le développement logiciel. Il ne fait pas autorité au sens propre. Cette notion de chef est bâtarde. Que ce soit dans les chiffrages ou dans les choix d’architecture, le développeur est autonome et se fait respecter. Ce n’est pas quelqu’un sorti de nul part qui va imposer un développement en x jours. Non non non ! Le développeur fait une estimation et c’est sur cette base que le planning se fait. Il peut y avoir des réajustements ou le chiffrage peut être optimisé mais ce n’est pas une relation hiérarchique: “code moi ça en x jours !”. Le chef de projet n’apporte aucune valeur ajoutée dans la construction logicielle contrairement aux architectes et développeurs. On lui demande bien parler et de bien communiquer mais il n’est pas le responsable hiérarchique de l’équipe. Il n’est pas qualifié pour cela.

La construction moderne d’un logiciel est orientée objet. Ce n’est pas simple et cela demande aux membres de l’équipe de modéliser et manipuler des quantités importantes de classes regroupées sous formes de hiérarchies et de savoir prendre du recul pour implémenter tous ses éléments sachant que des modifications dans une construction orientée objet alias OOP (interfaces, méthodes virtuelles, héritage de classes) peuvent être complexes et douloureuses…

La qualité dans le monde moderne n’est pas un option. Si un développeur réalise une construction de classes et que son utilisation est trop complexe, il doit y rajouter des choses, casses des choses, transformer et cela peut avoir des effets boules de neige. Seule la maturité du développeur permet de s’assurer qu’une implémentation est correcte la première fois sans avoir à y revenir après. Ceci n’est pas prévisible. La création de Test Unitaires via la conception permet de gérer cela. Cela veut dire qu’il faut prévoir ce temps de TUs.

Construire un logiciel via l’OOP c’est le fruit d’un travail scientifique de mise en relations d’éléments concrets issus d’abstractions et implémentés via des comportements dans des classes. On joue aux légos.

Y a ceux qui construisent les briques et y a ceux qui utilisent les briques. Ces deux catégories de développeurs ne font pas le même métier. Celui qui fait une brique réalise un travail de modélisation et met sa casquette d’Architecte et créé des classes. L’autre développeur ne fait que les utiliser… La travail collaboratif induit une communication permanente par exemple sur le confort d’utilisation des classes. Les interactions sont permanentes et un utilisateur de classe peut remonter un problème qui va nécessité au créateur de celle-ci de faire un fix ASAP et mettre à disposition une nouvelle version… cela peut provoquer des blocages.. Encore une fois, c’est un problème d’Architecture.

Quand une équipe est constitué d’éléments remarquables, il n’y a pas de hiérarchie. C’est la meilleur idée qui gagne. C’est le design le plus performant et le plus élégant qui l’emporte. Priorité à l’ingénierie.

Sans briser mon NDA avec Microsoft et mon accès au code source Windows, je peux vous dire que le code source de Windows, malgré son immensité est un travail d’orfèvre. On y trouve du C++ Moderne, des abstractions en pagailles, du code clean. Power & Peformance. Built on the metal !