La loi la plus puissante du logiciel
La structure d'un problème reflète la structure de l'organisation qui l'a créé...
En 1968, Melvin Conway a écrit un article contenant la déclaration suivante :
« Toute organisation qui conçoit un système, au sens large, concevra une structure qui sera la copie de la structure de communication de l’organisation. »
Vous connaissez peut-être déjà cela sous le nom de loi de Conway.
Cette déclaration de Conway pointe vers un problème connu : votre structure a un effet sur les logiciels que les membres de l'organisation produisent et expédient.
Pensez-y : la structure d'une organisation - qui fait partie de quelle équipe et comment ils parlent aux autres équipes, qui doit rendre compte à qui, etc. - a un effet sur le logiciel qu'elle produit. Non, vraiment, pensez-y : il ne s'agit pas des individus, de leurs talents et de leurs compétences ; il s'agit uniquement de la structure.
C'est un peu hallucinant, non? On pourrait penser que le logiciel, "seulement légèrement éloigné de la pensée pure", se tient au-dessus de ces contraintes terrestres telles que la façon dont les gens qui l'écrivent se parlent. Et pourtant, non.
Il y a quelques années, certaines personnes disaient que vous pouviez voir la structure (l’organigramme) de l’application lorsque vous ouvriez Spotify. On pouvait voir qu'il y avait une équipe responsable de la construction de l’image de l'application, du squelette, et les autres équipes qui ont construit les vues séparées à l'intérieur de l'application. Une équipe a construit la vue pour la recherche, une autre a construit la page d'accueil, une autre a construit la page de l'artiste, etc.
J'ai entendu dire la même chose à propos de Facebook il y a 10 ans : une équipe a construit le fil d'actualités, une autre équipe a construit la page des événements, une autre a construit la page des groupes, et puis il y avait des équipes pour les jeux, pour les photos, pour la messagerie , et ainsi de suite. Dans la barre de navigation sur le côté gauche, vous pouvez voir une liste des équipes d'ingénierie.
Quand j'ai entendu parler de la loi de Conway pour la première fois, je l’ai ignoré. Les entreprises dans lesquelles j'ai travaillé étaient soit si petites qu'il n'y avait pas d'organigramme à l'intérieur de l'organisation à proprement parler (toute l'ingénierie était dans une seule équipe) ou l'organigramme était dicté par le produit lui-même .
Nous avons créé des applications SaaS qui servaient quelques clients principalement : une application iOS, une application Android et l'interface Web. Toute l’organigramme était là : une équipe backend/web, une équipe iOS, une équipe Android. C’est tout. Je n'avais pas l'impression que la structure influençait notre produit, car, eh bien, nous voulions une application iOS et une application Android, n'est-ce pas ? Il n'y avait aucune friction entre ce que nous voulions livrer et l'organigramme.
Avec le recul, cependant, je peux voir la loi de Conway debout dans le coin de la pièce, souriant, attendant, pendant que nous discutions paresseusement si l’interface Web devrait être une équipe distincte de notre équipe backend.
Maintenant, avec les années, je commence à penser que la loi de Conway pourrait être la loi la plus puissante du logiciel. J'ai passé les dernières années à travailler sur différents produits, avec différentes équipes. Alors que nous étions une vingtaine d'employés parfois, d’autre fois, nous étions des centaines. Et à chaque fois, j'ai vu la loi de Conway.
Une partie du produit était bien conçue, une autre partie dormait - l'une avait une équipe, l'autre pas. Des rapports de bugs qui tombent dans les mailles du filet et disparaissent, car il n'y avait pas d'équipe claire à qui les affecter. Des structures de répertoires et des noms de fichiers qui vous font penser à l'organigramme. Les équipes se bottent le cul parce qu'elles veulent se concentrer sur leur propre part du produit, sans être dérangées par les préoccupations de ce qui se passe là-bas ou là-bas.
Encore une fois : on pourrait penser que les logiciels - des constructions intangibles et sans poids qui peuvent être voulues, façonnées pour correspondre aux rêves, envoyées dans le monde entier en une seconde, détruites ou reproduites des millions de fois, le tout d'une simple pression sur un bouton - flottent au-dessus tout ça. Mais y a-t-il une plus grande force dans la pièce dans laquelle le logiciel est écrit que la personne qui l'écrit ? Et ne savons-nous pas tous que, même si nous disons que nous ne le sommes pas, nous sommes influencés par le titre que vous nous donnez, le rôle que nous sommes censés jouer, avec qui nous travaillons, à quoi nous sommes mesurés ?
Nous savons également ce qui arrive à une base de code lorsque vous embauchez quelqu'un qui est vraiment, vraiment, vraiment dans la programmation fonctionnelle en ce moment ; ou lorsqu'un ancien programmeur Java rejoint une équipe PHP ; ou lorsque vous embauchez une personne DevOps qui aime Kubernetes et n'aime pas vraiment votre simple stack Heroku ; ou à quoi ressemblera votre zone d'administration lorsqu'elle appartiendra à des ingénieurs qui n'osent pas toucher au CSS ou au JavaScript.
C'est la loi de Conway, mais en zoom avant. Si ont zoom vers l’arrière : qu'advient-il d'une organisation lorsque vous dites qu'il doit maintenant y avoir une équipe frontend dédiée, ou une équipe SRE dédiée, ou une équipe Q&A, ou une équipe plate-forme, ou une équipe Kubernetes ? Votre produit lui ressemblera.
C'est la chose la plus fascinante pour moi : la loi de Conway n'est pas seulement quelque chose qui vous arrive, c'est quelque chose que vous pouvez voir, influencer et diriger. Si vous construisez un nouveau produit, la structure des équipes que vous décidez d'avoir aura beaucoup d'influence sur le produit comme n'importe quel wireframe.
Il y a un million de choses intéressantes à méditer : combien de temps faut-il pour que la structure organisationnelle mette sa marque sur un produit ? Certains produits sont-ils plus faciles à influencer que d'autres ? Les plateformes que vous déployez ne vous donnent-elles pas déjà un organigramme pour commencer ? Qu'en est-il du langage de programmation et de ses outils ? N'y a-t-il pas des individus qui échappent aux contraintes des équipes et mettent leur propre marque unique sur le logiciel, peu importe à qui il se rapporte ? Où les mettez-vous, pour maximiser l'effet?
Pure pensée, en effet.
Merci de m'avoir lu !