12 ms·

Scalability "requirements" are often misused by the developers so they get to play with "cool" and often very slow technologies at the owner's expense. I've see

by FpUser 4y ago

Scalability "requirements" are often misused by the developers so they get to play with "cool" and often very slow technologies at the owner's expense. I've seen it happen over and over.

dilyevsky 4y ago
Many experienced devs have ptsd from working themselves into a corner on unscalable stack which required death marches to resolve. Not surprisingly they often do a complete 180 after that. A strong cto / senior eng core would prevent the company from going to either extremes but unfortunately not many of them have that.
- fsociety 4y ago
  I am sure there is truth to this, but from my personal experience the death marches I have seen have come from overly complex designs which try to handle all future problems but then fail miserably. Whereas evolving a simple design to be more scalable often works out well. I am sure there are many situations this isn't true, but I have not seen them in my experience.
ARandomerDude 4y ago
This also becomes a self-creating problem where devs are afraid not to have played with the cool tech, lest they fail to have the golden resume.
JohnBooty 4y ago
Yeah. Resume-driven development. "Hey, we need k8s and/or huge AWS clusters because scalability" when often something simpler would suffice. At a previous position our devops guy had provisioned a cluster of god knows how many AWS Redis instances. I pointed out this was a lot more than we needed. He swore up and down we needed them because scalability. He had no idea how much data was in those things. LESS THAN A MEGABYTE of data. In the whole cluster. We had no plans to grow it, either. And we were only accessing it a few times per day. We didn't even need Redis. We could have just stored it in the database directly. He didn't know any of that, and he didn't care. Because it didn't matter. Resume-driven development. He wasn't stupid. He was very smart. He knew what he was doing. "Managed a Redis cluster" looks good on a resume. "Just used the database instead" does not.
- quadrifoliate 4y ago
  > He wasn't stupid. He was very smart. He knew what he was doing. "Managed a Redis cluster" looks good on a resume. "Just used the database instead" does not. Did your company fire him and replace him with a DBA instead? If not, then the resume driven development is working! I hate it when people look down on resume-driven development while simultaneously also doing things that promote it by letting HR people unrelated to technology screen resumes for recruiting. Here's a hint -- if your company is screening, even subconsciously for buzzword (and believe me, most of them do) then you are enabling resume-driven development whether you like it or not.
  - JohnBooty 4y ago
    Of course we were enabling it. Our CTO actually thought he was doing a good job.
    - Fanmade 4y ago
      You're almost exactyl describing what went down at my previous employer. The company already had a bunch of poorly written legacy systems which were used by about 50 clerks and written in PHP, Node.js and some .Net. They had problems with poor code and data quality, but none with performance. So they recruited a new CTO and a new Head of DevOps which planned the new infrastructure together. Of course now everything has to be split up in Microservices (or Nanoservices, because each one should basically have the least functionality possible) and thrown in the cloud. The only thing where a separate service actually makes sense are the machine learning processes that should extract information out of received documents. The rest could basically run in a basic PHP application on a Raspberry Pi without performance issues. When I quit that circus, development had basically stopped altogether and they were already paying five figure numbers each months just for hosting. I moved to a large corporation with the expectation that things should be better there. Turns out, that basically the same is happening on a larger scale. There they have a team of four guys having to manage more than a dozen microservices which were cut in strange ways. I am only a senior developer and no architect myself, but the ones I know are everywhere between crippling depressions and just laughing their asses of because of the stupidity that's going on in the tech world right now. There are companies where it's done properly, but either I have extremely bad luck in my surroundings, or those are an absolute minority.

by FpUser 4y ago

Scalability "requirements" are often misused by the developers so they get to play with "cool" and often very slow technologies at the owner's expense. I've seen it happen over and over.

dilyevsky 4y ago

Many experienced devs have ptsd from working themselves into a corner on unscalable stack which required death marches to resolve. Not surprisingly they often do a complete 180 after that. A strong cto / senior eng core would prevent the company from going to either extremes but unfortunately not many of them have that.

fsociety 4y ago
I am sure there is truth to this, but from my personal experience the death marches I have seen have come from overly complex designs which try to handle all future problems but then fail miserably. Whereas evolving a simple design to be more scalable often works out well. I am sure there are many situations this isn't true, but I have not seen them in my experience.

ARandomerDude 4y ago

This also becomes a self-creating problem where devs are afraid not to have played with the cool tech, lest they fail to have the golden resume.

JohnBooty 4y ago

Yeah. Resume-driven development. "Hey, we need k8s and/or huge AWS clusters because scalability" when often something simpler would suffice. At a previous position our devops guy had provisioned a cluster of god knows how many AWS Redis instances. I pointed out this was a lot more than we needed. He swore up and down we needed them because scalability. He had no idea how much data was in those things. LESS THAN A MEGABYTE of data. In the whole cluster. We had no plans to grow it, either. And we were only accessing it a few times per day. We didn't even need Redis. We could have just stored it in the database directly. He didn't know any of that, and he didn't care. Because it didn't matter. Resume-driven development. He wasn't stupid. He was very smart. He knew what he was doing. "Managed a Redis cluster" looks good on a resume. "Just used the database instead" does not.

quadrifoliate 4y ago
> He wasn't stupid. He was very smart. He knew what he was doing. "Managed a Redis cluster" looks good on a resume. "Just used the database instead" does not. Did your company fire him and replace him with a DBA instead? If not, then the resume driven development is working! I hate it when people look down on resume-driven development while simultaneously also doing things that promote it by letting HR people unrelated to technology screen resumes for recruiting. Here's a hint -- if your company is screening, even subconsciously for buzzword (and believe me, most of them do) then you are enabling resume-driven development whether you like it or not.
- JohnBooty 4y ago
  Of course we were enabling it. Our CTO actually thought he was doing a good job.
  - Fanmade 4y ago
    You're almost exactyl describing what went down at my previous employer. The company already had a bunch of poorly written legacy systems which were used by about 50 clerks and written in PHP, Node.js and some .Net. They had problems with poor code and data quality, but none with performance. So they recruited a new CTO and a new Head of DevOps which planned the new infrastructure together. Of course now everything has to be split up in Microservices (or Nanoservices, because each one should basically have the least functionality possible) and thrown in the cloud. The only thing where a separate service actually makes sense are the machine learning processes that should extract information out of received documents. The rest could basically run in a basic PHP application on a Raspberry Pi without performance issues. When I quit that circus, development had basically stopped altogether and they were already paying five figure numbers each months just for hosting. I moved to a large corporation with the expectation that things should be better there. Turns out, that basically the same is happening on a larger scale. There they have a team of four guys having to manage more than a dozen microservices which were cut in strange ways. I am only a senior developer and no architect myself, but the ones I know are everywhere between crippling depressions and just laughing their asses of because of the stupidity that's going on in the tech world right now. There are companies where it's done properly, but either I have extremely bad luck in my surroundings, or those are an absolute minority.