5 ms·

Can't we all just go back? Seriously every system I've worked on in the last 10 years seems worse in every metric than what I worked on 2000-2010.

by rr808 3y ago

pjmlp 3y ago
Kubernetes makes Websphere 5 development feel refreshing.
keyle 3y ago
There is no going back. The industry has seen a 5X raise in money and people. It's only natural that a job that used to take 2 now takes 10 people because of those facts. And I agree. We've traded safety and a few other things that could have been ironed out in exchange of massive gridlocks, headaches and colossal facepalms. Performance is only on par if you consider the hardware improvements, it's crazy.
- papito 3y ago
  We will be going back. After the last binge, torching through piles of cash to do resume-driven development, companies are now looking to be lean. You can't really survive if you are doing microservices and trying to actually build something with a team cut by 75%. I am already seeing this newly discovered love of simple, fast monoliths and the developer ergonomics they offer. What is old is new again - we are at the beginning of this cycle. The older generation learned that "complexity kills", the new generation is beginning to get it as well.
- Aeolun 3y ago
  If you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.
  - anonzzzies 3y ago
    The first thing I hear from the tech lead/CTO or whatever when I walk into a company is 'we are going to use microservices', then a lot of kubernetes, sqs, lambda etc. And THEN they talk about what the project is. I only didn't manage to keep away from a monolith for a fraction of the money and time; it was a huge fail; 20m$ burnt on engineers and aws and the endresult was a painful burning pile of nuclear waste. They had money to burn so they are still alive, but I should've walked out after the CTO pushed microservices past his team (his team + my team) who said it was nonsense in this case (it's in all cases, but whatever, I cannot prove that so).
  - orange8 3y ago
    What do you mean zero prestige in that? Do you know the difference in salary, importance and status in managing a team of 50 vs one of only two?
    - moosedev 3y ago
      I think you misread GP. That was the point they were making.
  - klabb3 3y ago
    Not just managers, but the senior engineers too. You can aggregate all the inter-service communication and say that you’re managing 1000 QPS service mesh rather than a meager backend with 10 QPS.
    - Marazan 3y ago
      Recently turned off a service that ran at 40,000 QPS
    - marginalia_nu 3y ago
      Not to mention the resume padding technology. You can no longer claim to have expertise in OpenShift, Redis, Kafka and RabbitMQ and machine learning from having implemented a todo app :-(
    - deleted 3y ago
      [deleted]
  - missingcolours 3y ago
    In the past and in other industries you'd choose the former because you'd get hit hard if your manager realized what you were doing. But in the easy-money FAANG world your manager is usually playing the same game, so they actually prefer that you go with the latter.
    - kqr 3y ago
      I agree. These decisions are not made economically, they are made politically. And the big complicated thing is far more prestigious. Then let's say half of our profession has less than five years of experience (though I would guess it's closer to two years) -- they see what the elders do and copy that, like any good apprentice would. Suddenly, it's all they know. Wild conjecture, of course. I would like to see it studied!
  - rqtwteye 3y ago
    Even for a tech lead the former is definitely very bad for your resume. You pretty much kill your own career.
  - byyyy 3y ago
    Because we can't definitively prove which one is better. There is no formal theory around system design so you get people complaining about how monoliths are error prone and way too complex and you get people complaining about microservices with the exact same argument. The result is that with a period of about a decade the industry just oscillates between the two methodologies in an endless flat circle. Monoliths will come in vogue again in the 2020s.
    - marginalia_nu 3y ago
      Yeah. I think what it boils down to is inexperienced developers and shortsighted product managers are capable of bad design choices in any paradigm. And handing them a new paradigm that's en vogue will all but guarantee they'll mess it up. Perhaps the real crux is that large teams don't build good software. Especially not from the ground up.
    - ozim 3y ago
      Fun part is there is no “better” in generic terms. Another fun part is that people on the internet complain but without merit. I cannot judge some project because I usually don’t know the project. So might as well be that monolith or not team was having high attrition or there might be many other things that would affect project.
      - byyyy 3y ago
        >Fun part is there is no “better” in generic terms. No. It goes further then this. We actually don't even know if one is better or not. There is no formal theory that allows us to prove these designs. For example we have formal theory behind algorithm complexity that quantifies runtime cost but no such theory exists for engineering design patterns. We aren't even sure what to quantify. But just because a formal theory doesn't yet exist doesn't mean one can be developed in the future. Until then these system designs will be like history... Always repeating itself.
  - deleted 3y ago
    [deleted]
  - EasternGuy 3y ago
    On a vaguely related note but still shows how the World works. Back in 1992, my Eastern European computer science teacher told us a story. He used to work as a programmer, doing "ERP" software for communist companies (state-owned, of course). The software would run on machines featuring Z80 CPU with CP/M operating system. Anyhow after the change of regime they got 386 PCs and rewrote the software to run on them. The performance gain was staggering but ... users (directors of said companies) complained. The software would cost a lot but seemengly would not "work hard" for it. On the old machines it would take a lot of time to process anything, it was obvious the software was "working hard". On the PCs the same operation which would take minutes or hours would complete instantly. Obviously the job was too easy and thus much overpriced. Faced with this serious problem impacting sales, the programmers thought about it and eventually found a solution. They added... SLEEP instructions. All over the code in key points, sleep(seconds), calibrated so the response time was about the same as on ye olde CP/Me machines. Customer reaction: completely satisfied. ... I think we can draw some conclusions on the universality of human stupidity and incentives to act that way.
    - jowdones 3y ago
      This shows what they failed to consider in those optimistic views of the 1930s like John Maynard Keynes who predicted that his grandkids would work just 15 hours a week. Slaves don't trade productivity for their lives, they trade time. No matter how many trillions of times more productive human activities will become, slaves's time will still belong to the masters and very little of their life will belong to them.
      - disgruntledphd2 3y ago
        [flagged]
        jowdones 3y ago
        So using the "wage slave" rethoric is punished now by the Thought Police. Happy happy thoughts and be greatful for the opportunity to trade our lives for a measly pay working for the man.
- granshaw 3y ago
  All the laid off tech workers disagree
pbreit 3y ago
Agree. Very few systems benefit from the increased complexity and decreased productivity. DHH has a couple of posts on the topic recently: https://world.hey.com/dhh/how-to-recover-from-microservices-ce3803cc https://world.hey.com/dhh/how-to-recover-from-microservices-...
- intelVISA 3y ago
  Rare case of DHH being cogent, I wonder if this was a result of him rediscovering Traefik and Docker Swarm?
  - wmf 3y ago
    He's always been pushing monoliths.
    - intelVISA 3y ago
      Then I ask forgiveness for ever doubting him. Can he help us turn back from this Cloud Hellscape?
      - rubyskills 3y ago
        He is attempting it! I've been following his journey moving his apps out of the cloud and I just say it, I want to try some of his deployment tooling he's making as a result.
1vuio0pswjnm7 3y ago
People doing development/marketing/sales of software for money will not go back, but end users who can write software could go back. The systems can be worse because of what other commenters mention, the financial incentives, but also the companies profiting from worse systems must ensure that expectations are gradually lowered amongst people who write software and that these peoples' "skills" are progressively dumbed down. That is how they ensure that status quo is maintained and that people will never "go back". Meanwhile, hardware and networking improvements have been amazing.

Can't we all just go back? Seriously every system I've worked on in the last 10 years seems worse in every metric than what I worked on 2000-2010.

by rr808 3y ago

Can't we all just go back? Seriously every system I've worked on in the last 10 years seems worse in every metric than what I worked on 2000-2010.

pjmlp 3y ago

Kubernetes makes Websphere 5 development feel refreshing.

keyle 3y ago

There is no going back. The industry has seen a 5X raise in money and people. It's only natural that a job that used to take 2 now takes 10 people because of those facts. And I agree. We've traded safety and a few other things that could have been ironed out in exchange of massive gridlocks, headaches and colossal facepalms. Performance is only on par if you consider the hardware improvements, it's crazy.

papito 3y ago
We will be going back. After the last binge, torching through piles of cash to do resume-driven development, companies are now looking to be lean. You can't really survive if you are doing microservices and trying to actually build something with a team cut by 75%. I am already seeing this newly discovered love of simple, fast monoliths and the developer ergonomics they offer. What is old is new again - we are at the beginning of this cycle. The older generation learned that "complexity kills", the new generation is beginning to get it as well.
Aeolun 3y ago
If you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.
- anonzzzies 3y ago
  The first thing I hear from the tech lead/CTO or whatever when I walk into a company is 'we are going to use microservices', then a lot of kubernetes, sqs, lambda etc. And THEN they talk about what the project is. I only didn't manage to keep away from a monolith for a fraction of the money and time; it was a huge fail; 20m$ burnt on engineers and aws and the endresult was a painful burning pile of nuclear waste. They had money to burn so they are still alive, but I should've walked out after the CTO pushed microservices past his team (his team + my team) who said it was nonsense in this case (it's in all cases, but whatever, I cannot prove that so).
- orange8 3y ago
  What do you mean zero prestige in that? Do you know the difference in salary, importance and status in managing a team of 50 vs one of only two?
  - moosedev 3y ago
    I think you misread GP. That was the point they were making.
- klabb3 3y ago
  Not just managers, but the senior engineers too. You can aggregate all the inter-service communication and say that you’re managing 1000 QPS service mesh rather than a meager backend with 10 QPS.
  - Marazan 3y ago
    Recently turned off a service that ran at 40,000 QPS
  - marginalia_nu 3y ago
    Not to mention the resume padding technology. You can no longer claim to have expertise in OpenShift, Redis, Kafka and RabbitMQ and machine learning from having implemented a todo app :-(
  - deleted 3y ago
    [deleted]
- missingcolours 3y ago
  In the past and in other industries you'd choose the former because you'd get hit hard if your manager realized what you were doing. But in the easy-money FAANG world your manager is usually playing the same game, so they actually prefer that you go with the latter.
  - kqr 3y ago
    I agree. These decisions are not made economically, they are made politically. And the big complicated thing is far more prestigious. Then let's say half of our profession has less than five years of experience (though I would guess it's closer to two years) -- they see what the elders do and copy that, like any good apprentice would. Suddenly, it's all they know. Wild conjecture, of course. I would like to see it studied!
- rqtwteye 3y ago
  Even for a tech lead the former is definitely very bad for your resume. You pretty much kill your own career.
- byyyy 3y ago
  Because we can't definitively prove which one is better. There is no formal theory around system design so you get people complaining about how monoliths are error prone and way too complex and you get people complaining about microservices with the exact same argument. The result is that with a period of about a decade the industry just oscillates between the two methodologies in an endless flat circle. Monoliths will come in vogue again in the 2020s.
  - marginalia_nu 3y ago
    Yeah. I think what it boils down to is inexperienced developers and shortsighted product managers are capable of bad design choices in any paradigm. And handing them a new paradigm that's en vogue will all but guarantee they'll mess it up. Perhaps the real crux is that large teams don't build good software. Especially not from the ground up.
  - ozim 3y ago
    Fun part is there is no “better” in generic terms. Another fun part is that people on the internet complain but without merit. I cannot judge some project because I usually don’t know the project. So might as well be that monolith or not team was having high attrition or there might be many other things that would affect project.
    - byyyy 3y ago
      >Fun part is there is no “better” in generic terms. No. It goes further then this. We actually don't even know if one is better or not. There is no formal theory that allows us to prove these designs. For example we have formal theory behind algorithm complexity that quantifies runtime cost but no such theory exists for engineering design patterns. We aren't even sure what to quantify. But just because a formal theory doesn't yet exist doesn't mean one can be developed in the future. Until then these system designs will be like history... Always repeating itself.
- deleted 3y ago
  [deleted]
- EasternGuy 3y ago
  On a vaguely related note but still shows how the World works. Back in 1992, my Eastern European computer science teacher told us a story. He used to work as a programmer, doing "ERP" software for communist companies (state-owned, of course). The software would run on machines featuring Z80 CPU with CP/M operating system. Anyhow after the change of regime they got 386 PCs and rewrote the software to run on them. The performance gain was staggering but ... users (directors of said companies) complained. The software would cost a lot but seemengly would not "work hard" for it. On the old machines it would take a lot of time to process anything, it was obvious the software was "working hard". On the PCs the same operation which would take minutes or hours would complete instantly. Obviously the job was too easy and thus much overpriced. Faced with this serious problem impacting sales, the programmers thought about it and eventually found a solution. They added... SLEEP instructions. All over the code in key points, sleep(seconds), calibrated so the response time was about the same as on ye olde CP/Me machines. Customer reaction: completely satisfied. ... I think we can draw some conclusions on the universality of human stupidity and incentives to act that way.
  - jowdones 3y ago
    This shows what they failed to consider in those optimistic views of the 1930s like John Maynard Keynes who predicted that his grandkids would work just 15 hours a week. Slaves don't trade productivity for their lives, they trade time. No matter how many trillions of times more productive human activities will become, slaves's time will still belong to the masters and very little of their life will belong to them.
    - disgruntledphd2 3y ago
      [flagged]
      - jowdones 3y ago
        So using the "wage slave" rethoric is punished now by the Thought Police. Happy happy thoughts and be greatful for the opportunity to trade our lives for a measly pay working for the man.
granshaw 3y ago
All the laid off tech workers disagree

pbreit 3y ago

Agree. Very few systems benefit from the increased complexity and decreased productivity. DHH has a couple of posts on the topic recently: https://world.hey.com/dhh/how-to-recover-from-microservices-ce3803cc https://world.hey.com/dhh/how-to-recover-from-microservices-...

intelVISA 3y ago
Rare case of DHH being cogent, I wonder if this was a result of him rediscovering Traefik and Docker Swarm?
- wmf 3y ago
  He's always been pushing monoliths.
  - intelVISA 3y ago
    Then I ask forgiveness for ever doubting him. Can he help us turn back from this Cloud Hellscape?
    - rubyskills 3y ago
      He is attempting it! I've been following his journey moving his apps out of the cloud and I just say it, I want to try some of his deployment tooling he's making as a result.

1vuio0pswjnm7 3y ago

People doing development/marketing/sales of software for money will not go back, but end users who can write software could go back. The systems can be worse because of what other commenters mention, the financial incentives, but also the companies profiting from worse systems must ensure that expectations are gradually lowered amongst people who write software and that these peoples' "skills" are progressively dumbed down. That is how they ensure that status quo is maintained and that people will never "go back". Meanwhile, hardware and networking improvements have been amazing.