When Martin Fowler's post about microservices came out in 2014, the teams where I worked were already building service-oriented architectures. That post and the subsequent hype made their way into almost every software team in the world. The "Netflix OSS stack" was the coolest thing back then, allowing engineers worldwide to leverage Netflix's lessons in distributed systems. More than six years later, if we look into software engineering jobs right now, most of them talk about a microservices' architecture.
In the earliest part of the 2010s, many organizations were suffering challenges regarding their software development cycle. Folks working with other 50, 100 or 200 engineers struggled with development environments, heavy QA processes and programmed deployments. While Martin Fowler's "Continuous Delivery" book shed light on many of those teams, they started to realize their majestic monoliths were creating organizational problems for them. Hence, microservices were appealing for software engineers. It's more challenging to introduce continuous delivery or deployment in a big project rather than start with it.
La huitième plaie. Un article qui se lit bien, une chambre d’écho qui fait du bien (surtout en ce moment). J’aime bien les articles un peu « histoire » sur de la hype en informatique, je trouve qu’on en trouve encore trop peu pour comprendre le chemin que fait notre domaine.
The analysis provided above demonstrates that systems thinking, as a personal mental disposition, besides being a trivial idea, is essentially orthogonal to the social problem of alignment. Aligning business and IT elements of organisations requires improving interpersonal information exchange between various stakeholders and establishing collaborative decision-making procedures, rather than merely thinking differently. For this reason, systems thinking on its own, no matter how well-developed, is unable to deliver any significant organisational enhancements (besides that, it is also debatable whether, or to what extent systems thinking can be developed in an individual). In other words, systems thinking as a paradigm for EA practitioners is mostly futile, it cannot really benefit EA practices and drive the EA discipline forward.
Selon l’article, soit on utilise du system thinking tout seul pour élaborer l’archi parfaite qui ne verra jamais le jour, soit on communique avec les gens pour trouver une solution imparfaite mais qu’on pourra appliquer. Bien que je comprenne sa stratégie de dégrader le premier pour élever le second pour éveiller l’intérêt des archi qui se seraient perdus dans leurs outils, je pense que les approches ne sont ni exclusives ni orthogonales. Mais plutôt que sans la communication on ne peut pas avoir la matière pour penser le système, et qu’aussi abstrait que puisse être le system thinking ce dernier permet à l’architecte d’apporter une perspective au groupe durant la communication lorsqu’il s’agit de mettre les gens d’accord, un peu à la façon décrite par Gregor Hohpe dans son article Architects See More Dimensions. J’ai tout de même bien aimé cet article, facile à lire, et le message est bien évident !
I often struggle to explain what it means to be part of a high-functioning software team. Sure, there are mountains of literature, and an entire genre of LinkedIn thought leadership that professes all kinds of guidelines and heuristics about what makes teams work, but in my experience, it’s hard to internalize these ideas and follow someone else’s model if you’ve never seen what good looks like. I’ve been very lucky to have worked directly with dozens, if not hundreds, of developers by this point in my career. I’ve been on some unhealthy teams: teams where people were fearful, and held their cards very close to their chest out of a perceived or real worry around their job security. I’ve also been on dysfunctional teams, where many days or weeks of development time was wasted while the team whiplashed between unclear priorities, or where the cost of coordination had grown so high that no one simply wanted to do it, leaving team as a collective of individuals rather than a unit. But I’ve luckily spent time on some very high-performing teams. When I’ve been on those teams, I was excited to come to work everyday, I wasn’t afraid of disagreeing publicly with those more senior than me, and I felt like my voice and my work had impact. In this post, I’ll try to document the characteristics and habits of the highest-performing teams I’ve been on.
"This." comme ils disent. J’ai vécu ce type de contexte à haute sécurité psychologique (cc DAB 👋). Et même quand on en fait partie, l’efficacité du groupe arrive encore à impressionner. Je rêve de retrouver un tel contexte, mais de façon plus permanente. C’est ce qui me fera quitter le conseil, même si c’est pour le construire.
Writing about something teaches you about what you know, what you don’t know, and how to think. Writing about something is one of the best ways to learn about it. Great writing requires you to position your idea in a way that will resonate with the reader.
Découvrez pourquoi l'écriture est importante, même dans un monde où l'IA peut écrire pour vous. L'écriture vous apprend à penser et à comprendre les problèmes en profondeur, ce qui est essentiel pour résoudre les problèmes difficiles. De plus, une bonne écriture nécessite de positionner votre idée de manière à ce qu'elle résonne avec le lecteur. Merci l’IA d’avoir rédigé ce résumé pour moi. Plus sérieusement: oui, ça aide à produire le discours, mais lorsqu’on écrit pour d’autres il ne faut pas oublier que notre discours interne (l’enchaînement d’idées visant à formuler notre connaissance) n’est pas nécessairement adapté à la transmission à un tiers. Autrement dit, la chaine d’idées doit partir de ce qu’on sait que nos interlocuteurs savent (parait que ça va sans dire, mais ça va mieux en le disant), et c’est notamment par ce biais là qu’on apprend en transmettant.
