JaiLu la note de David Larlet nommée Initiateurs et mainteneurs.
There are two roles for any project: starters and maintainers. People may play both roles in their lives, but for some reason I’ve found that for a single project it’s usually different people. Starters are good at taking a big step in a different direction, and maintainers are good at being dedicated to keeping the code alive.
…
I am definitely a starter. I tend to be interested in a lot of various things, instead of dedicating myself to a few concentrated areas. I’ve maintained libraries for years, but it’s always a huge source of guilt and late Friday nights to catch up on a backlog of issues.
Je suis également un initiateur. J’aime créer de nouvelles choses en expérimentant des usages et des techniques. Lorsque je me retrouve dans un rôle de mainteneur, j’ai tendance à complexifier l’existant et à le rendre moins stable par ma soif d’apprendre de nouvelles choses. Or l’apprentissage nait de l’échec et du test des limites. C’est assez désastreux pour les projets et je pense que l’engouement pour les microservices est un complot des initiateurs en mal d’expérimentations au sein d’applications à maintenir. À moins que la maintenance soit un vestige du passé (cache).
— from
Ces réflexions résonnent profondément en moi 🤗, car ce sont des questions et des pensées qui m’habitent depuis de nombreuses années.
« j’ai tendance à complexifier l’existant et à le rendre moins stable par ma soif d’apprendre de nouvelles choses »
Pour éviter cette tendance à complexifier l’existant, j’utilise la stratégie suivante. Lorsque je ressens le besoin d’expérimenter ou d’apprendre quelque chose de nouveau, je le fais au travers des side projects personnels ou dans le cadre de POC (Proof of Concept) et Spike officiellement décidés en équipe. C’est entre autres pour cette raison que j’avais proposé de mettre en place les Spike and Learn Day.
Cette approche me permet de satisfaire ma curiosité et mon envie d’apprendre, tout en maintenant l’utilisation de Boring Technology pour les projets critiques ou ceux menés en équipe. Ainsi, je parviens à éviter le piège du Resume Driven Development.
J’aime bien la distinction suivante :
« There are two roles for any project: starters and maintainers »
Jusqu’à présent, j’ai tendance à utiliser le terme solo développeurs pour les “starters” et team développeurs pour les “maintainers”.
Petite anecdote amusante : lors de mon expérience chez Spacefill, j’avais proposé de nommer le rôle des développeurs d’expérience au sein de l’équipe les “maintainers” 😉.
« C’est assez désastreux pour les projets et je pense que l’engouement pour les microservices est un complot des initiateurs en mal d’expérimentations au sein d’applications à maintenir. »
C’est une réflexion que j’ai moi-même eue par le passé.
Je crois en effet que les solo développeurs apprécient particulièrement les microservices et les multi repository car cela leur permet d’éviter les contraintes d’équipes.
Cela leur permet d’explorer des nouveaux langages et frameworks et d’échaper aux revues de code.
À mes yeux, cette approche favorise davantage l’individualisme que la cohésion d’équipe.
J’ai également remarqué que c’est souvent lors des phases de storming du modèle de Tuckman que les développeurs semblent se tourner vers les microservices comme une forme d’évitement des défis collectifs. Cette stratégie peut sembler séduisante, mais elle risque de renforcer les silos et de freiner la collaboration au sein de l’équipe 🤔.