4 ms·

Organizing around software components is such an idiotic idea. Good luck changing your design or making end-to-end features when you have teams protecting "th

Organizing around software components is such an idiotic idea. Good luck changing your design or making end-to-end features when you have teams protecting "their" part of the software. You've just made sure that any significant change to the system requires coordinating many different teams, making it at least one order more difficult than before, and a lot more bureaucratic.

peterangular 4y ago
For my anecdotal experience, microservices is the introduction of fiefdoms in development. And, I get it. Selfishly I would love to come onto a project and only have to worry about net-new development. It is hard to learn, and then positively contribute within another engineered system... of any complexity. When it's "my code" I tend to be much more productive, and it's easier to find my way through the forest. Anymore, everyone is on a power-grab for "my tools" and "my way" in regards to everything they're working on with near-zero attempt to understand the base needs of the business/feature. Microservices fill this need well as devs can work with their preferred toolset and just setup I/O boundaries for everyone else to use their service. Also, this is good for resume-driven development as you can often claim creation/ownership over some "piece" which looks way better on paper vs. "contributed to a big 'ol project." I'm not against microservices, I'm just being honest with how I've seen them socially play out - all of this is anecdotal to my experiences.
- dragonwriter 4y ago
  > For my anecdotal experience, microservices is the introduction of fiefdoms in development. Fiefdoms, whether implicit or explicit, are pervasive in organizations beyond trivial size; IME, software architecture choices may impact the shape of the fiefdoms, but not their existence.
deleted 4y ago
[deleted]

4 ms·

Organizing around software components is such an idiotic idea. Good luck changing your design or making end-to-end features when you have teams protecting "th

by strictfp 4y ago

peterangular 4y ago
For my anecdotal experience, microservices is the introduction of fiefdoms in development. And, I get it. Selfishly I would love to come onto a project and only have to worry about net-new development. It is hard to learn, and then positively contribute within another engineered system... of any complexity. When it's "my code" I tend to be much more productive, and it's easier to find my way through the forest. Anymore, everyone is on a power-grab for "my tools" and "my way" in regards to everything they're working on with near-zero attempt to understand the base needs of the business/feature. Microservices fill this need well as devs can work with their preferred toolset and just setup I/O boundaries for everyone else to use their service. Also, this is good for resume-driven development as you can often claim creation/ownership over some "piece" which looks way better on paper vs. "contributed to a big 'ol project." I'm not against microservices, I'm just being honest with how I've seen them socially play out - all of this is anecdotal to my experiences.
- dragonwriter 4y ago
  > For my anecdotal experience, microservices is the introduction of fiefdoms in development. Fiefdoms, whether implicit or explicit, are pervasive in organizations beyond trivial size; IME, software architecture choices may impact the shape of the fiefdoms, but not their existence.
deleted 4y ago
[deleted]