16
Everything Started with the Promise of Loosely Coupled Systems
(newsletter.systemdesignclassroom.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 17 May 2025
16 points (83.3% liked)
Programming
20196 readers
469 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
I am so tired of these sorts of shallow analyses from people that think their screw-ups are actually caused by EDAs or micro services or whatever. They're even totally transparent about the fact that they did because they heard cool things but never say "so we sat down to learn about best practices, what the current state of the art is, and considered how our use cases matched the architecture"
They just say "we thought it would be cool so we just started doing it and it sucked - here's why that's an inherent problem of the architecture and not in any way related to our behavior".
Yes. If you take a team of people who build n-tier and hexagonal MVC monolithic apps, and then tell them to build micro services, they're going to build a bunch of n-tier or hexagonal MVC monolith candidates and eventually end up with a single service that does too much and ultimately becomes the monolith.
Yes. If you take a team that does 100% synchronous HTTP interfaces, SOAP or ReST, and then tell them to build microservices, they're going to daisy chain those microservices via synchronous HTTP interfaces, and if you tell them to build an EDA they are going to build an EDA that attempt to replicate all of the aspects of their synchronous HTTP interfaces with busy polling loops.
So stop doing that and actually do the hard thing of learning fundamentally different architecture, techniques, technologies, trade offs, best practices, operational patterns, design patterns, and heuristics and principles for managing software. Learning is difficult and humbling. But it sure beats writing ignorant articles like this.
Glad I'm not the only one who read the article and thought it sounded like failures of research and planning more than anything.
And last I'm going to bring up a pet peeve; maybe it's related or maybe I'm just projecting. Agile doesn't fucking mean make the story work in a sprint and think about nothing else. I see far too many developers and PMs both with the attitude of just making it work and iterating/improving will happen later. What you end up with is architecture by accident, which is exactly what this sounds like. You're going to constantly have sprints redoing a bunch of work when your architecture starts to coalesce and nothing fits, or you're going to have spaghetti with code duplication and awkward coupling everywhere.
Agile is great, but don't fuck it up by thinking vibe architecting is a thing. Plan shit, create standards, enforce them. Acceptance criteria isn't the end all be all of story success.
I've seen some shit.