5 ms·

Microservices are not solving a technical problem. This is related to another issue: many technical people think tech is the hard part. Technology is the easy p

Microservices are not solving a technical problem. This is related to another issue: many technical people think tech is the hard part. Technology is the easy part. If you think the tech is hard, you have no idea how hard The Rest is. I know it sucks, but the sooner you learn this the better.

twelfthnight 2y ago
So true. Communication is insanely difficult. Hiring competent, motivated engineers is insanely difficult. Working around short-term thinking executives is insanely difficult. Iterating until you stumble on a success product is insanely difficult. How often does anyone talk about these problems in meetings? It's wild, I feel like all I ever do is argue over mostly irrelevant technical minutia.
- huygens6363 2y ago
  Exactly! It's this huge elephant in the room and all we want to talk about is our editors and how Java is faster than Go or whatever. I'm sitting in this meetings thinking "Guys, using XML or JSON truly, truly does not matter here. You have already wasted months on this shit and the value meter is still at $0. I'm telling you we can make this work with either Scala or 6502 assembly or anything in between. What matters is that we need a coherent vision, formulate actionable goals and work on improving our communication and keeping it there." Maybe I need to go into management? (/s ?)
  - anon64765446 2y ago
    It's almost as if you are describing the meetings in my company (and my previous) I think focusing on technical trivialities is a symptom of what type of experience the developers have and how the current workplace is organized. In traditional companies, the developers are at the tail of a process that they have limited participation in. Most of the product decisions has been done by others and the developers often don't have enough contact with the business side to make any real impact. You end up with an isolated group that can only influence technical desicions, so that's what they will focus on. Choosing tech X vs tech Y is actually only 1 choice in a long chain of product, design and business choices that has led to the Jira ticket. From their point of view, it seems like the most important desicion because it is taken out of context. This is where experience is actually a good thing, because it increases the chance that you have been exposed to "the other side". They will also know that these types of decisions are not likely to be the reason why they fail. By participating from the beginning you also tend to be more motivated by outcome. Technical discussions that don't have a real impact become less interesting.
    - twelfthnight 2y ago
      This resonates with me, although I would go a step further to say the makeup/experience of the developers is a product of the competency of leadership. Most leaders wind up in their positions out of pure luck and chicanery. I can't tell you how many lay offs I've been through where the best people are let go and the worst are kept on and unintentionally sabotage the entire engineering team.
    - wruza 2y ago
      focusing on technical trivialities is a symptom of what type of experience the developers have and how the current workplace is organized It comes from development echo chambers (including this one, sorry HN), where people tend to discuss The Right Way even if they see it not working at their own job, cause right ways feel good. New/young developers absorb it and bring it to their workplace. I did that too. It took decades to beat this shit out of myself. Now when I hear someone talking about true ways of a qualified professional developer I just remember that the business will probably pivot a couple of times before they deliver an mvp that is neither v or p.
  - twelfthnight 2y ago
    I for one would love to have a boss that cares about those things.
- nikau 2y ago
  welcome to bike shedding https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality
hakunin 2y ago
Trying to solve a communication problem with more code and infra is often a mistake. This is something many engineers don't realize they're essentially doing. Some communication problems can be somewhat alleviated by processes and technology enforcing those processes, but you must always consider the cost, and weigh it against alternatives that don't require engineering overhead. In almost every case like this, increasing the amount of code and infrastructure is the wrong option.
- from-nibly 2y ago
  Yes, but Conway is not wrong
  - hakunin 2y ago
    Yes, but his law is descriptive, not prescriptive. Just because it tends to happen doesn't mean it should happen, or happens for good reasons.
    - from-nibly 2y ago
      But it means it happens. So you can either weaponize it or get steam rolled by it.
  - gilbetron 2y ago
    Not wrong, but also not a Law.
mattgreenrocks 2y ago
> If you think the tech is hard, you have no idea how hard The Rest is. If people/orgs really believed this, they'd keep headcount as minimal as possible.
- DowagerDave 2y ago
  Don't they? The only experience I've had where this isn't the case is startup mania, where gasoline is poured over open flame.
  - mattgreenrocks 2y ago
    It really depends on where you work I suspect. Some places incentivize having lots of direct reports and hiring can outpace the ability to dole out work. Currently some of those places seem to be seeing how few developers they actually need to keep the lights on. In both cases the decision isn't made from a technical POV but more just following the current fashions.
red_admiral 2y ago
I always thought microservices did solve a technical problem, but one that only appears when you're the size of Twitter or similar. I would agree with you for the huge majority of companies that don't build their own datacenters.
- huygens6363 2y ago
  It's an organizational pattern. I've seen it being used at very small companies to good effect. It matched their (dysfunctional) culture: islands, little communication, etc. Working on a monolith together is a nightmare if you hate each other.
zelphirkalt 2y ago
It depends on what kind of tech we are talking about. Making a truly good and flexible tech product is truly hard. There will always be someone arguing YAGNI at inappropriate moments, influencing design negatively in ways, that will usually never be overthrown again, because of the additional mindset of not wanting rewrites and mindset of not wanting to change a (halfassed) working system.
intelVISA 2y ago
Many vogue tech decisions are over-engineered band-aids for organizational dysfunction.

twelfthnight 2y ago

So true. Communication is insanely difficult. Hiring competent, motivated engineers is insanely difficult. Working around short-term thinking executives is insanely difficult. Iterating until you stumble on a success product is insanely difficult. How often does anyone talk about these problems in meetings? It's wild, I feel like all I ever do is argue over mostly irrelevant technical minutia.

huygens6363 2y ago
Exactly! It's this huge elephant in the room and all we want to talk about is our editors and how Java is faster than Go or whatever. I'm sitting in this meetings thinking "Guys, using XML or JSON truly, truly does not matter here. You have already wasted months on this shit and the value meter is still at $0. I'm telling you we can make this work with either Scala or 6502 assembly or anything in between. What matters is that we need a coherent vision, formulate actionable goals and work on improving our communication and keeping it there." Maybe I need to go into management? (/s ?)
- anon64765446 2y ago
  It's almost as if you are describing the meetings in my company (and my previous) I think focusing on technical trivialities is a symptom of what type of experience the developers have and how the current workplace is organized. In traditional companies, the developers are at the tail of a process that they have limited participation in. Most of the product decisions has been done by others and the developers often don't have enough contact with the business side to make any real impact. You end up with an isolated group that can only influence technical desicions, so that's what they will focus on. Choosing tech X vs tech Y is actually only 1 choice in a long chain of product, design and business choices that has led to the Jira ticket. From their point of view, it seems like the most important desicion because it is taken out of context. This is where experience is actually a good thing, because it increases the chance that you have been exposed to "the other side". They will also know that these types of decisions are not likely to be the reason why they fail. By participating from the beginning you also tend to be more motivated by outcome. Technical discussions that don't have a real impact become less interesting.
  - twelfthnight 2y ago
    This resonates with me, although I would go a step further to say the makeup/experience of the developers is a product of the competency of leadership. Most leaders wind up in their positions out of pure luck and chicanery. I can't tell you how many lay offs I've been through where the best people are let go and the worst are kept on and unintentionally sabotage the entire engineering team.
  - wruza 2y ago
    focusing on technical trivialities is a symptom of what type of experience the developers have and how the current workplace is organized It comes from development echo chambers (including this one, sorry HN), where people tend to discuss The Right Way even if they see it not working at their own job, cause right ways feel good. New/young developers absorb it and bring it to their workplace. I did that too. It took decades to beat this shit out of myself. Now when I hear someone talking about true ways of a qualified professional developer I just remember that the business will probably pivot a couple of times before they deliver an mvp that is neither v or p.
- twelfthnight 2y ago
  I for one would love to have a boss that cares about those things.
nikau 2y ago
welcome to bike shedding https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality

hakunin 2y ago

Trying to solve a communication problem with more code and infra is often a mistake. This is something many engineers don't realize they're essentially doing. Some communication problems can be somewhat alleviated by processes and technology enforcing those processes, but you must always consider the cost, and weigh it against alternatives that don't require engineering overhead. In almost every case like this, increasing the amount of code and infrastructure is the wrong option.

from-nibly 2y ago
Yes, but Conway is not wrong
- hakunin 2y ago
  Yes, but his law is descriptive, not prescriptive. Just because it tends to happen doesn't mean it should happen, or happens for good reasons.
  - from-nibly 2y ago
    But it means it happens. So you can either weaponize it or get steam rolled by it.
- gilbetron 2y ago
  Not wrong, but also not a Law.

mattgreenrocks 2y ago

> If you think the tech is hard, you have no idea how hard The Rest is. If people/orgs really believed this, they'd keep headcount as minimal as possible.

DowagerDave 2y ago
Don't they? The only experience I've had where this isn't the case is startup mania, where gasoline is poured over open flame.
- mattgreenrocks 2y ago
  It really depends on where you work I suspect. Some places incentivize having lots of direct reports and hiring can outpace the ability to dole out work. Currently some of those places seem to be seeing how few developers they actually need to keep the lights on. In both cases the decision isn't made from a technical POV but more just following the current fashions.

red_admiral 2y ago

I always thought microservices did solve a technical problem, but one that only appears when you're the size of Twitter or similar. I would agree with you for the huge majority of companies that don't build their own datacenters.

huygens6363 2y ago
It's an organizational pattern. I've seen it being used at very small companies to good effect. It matched their (dysfunctional) culture: islands, little communication, etc. Working on a monolith together is a nightmare if you hate each other.

zelphirkalt 2y ago

It depends on what kind of tech we are talking about. Making a truly good and flexible tech product is truly hard. There will always be someone arguing YAGNI at inappropriate moments, influencing design negatively in ways, that will usually never be overthrown again, because of the additional mindset of not wanting rewrites and mindset of not wanting to change a (halfassed) working system.

intelVISA 2y ago

Many vogue tech decisions are over-engineered band-aids for organizational dysfunction.