people will use it not because it's good or even necessary, but because it will ensure their employment
Utter nonsense.
Developers use these frameworks (a) because they like it, (b) because there is a wealth of knowledge on the internet about how to fix every little problem, (c) because it allows them to be productive with their peers and (d) because often they learn something new. People get bored doing the same thing over and over again for 30 years like you seem to be advocating for.
Imagine going to a doctor and getting a prescription because "they like it".
there is a wealth of knowledge on the internet about how to fix every little problem
Let's hope they're using the same version you're using.
because it allows them to be productive with their peers
Productivity without a framework must be impossible...
they learn something new
They learn something about the framework at the present time, which may be worthless after the next breaking change, and is not generally applicable to the web platform itself.
They learn something about the framework at the present time, which may be worthless after the next breaking change, and is not generally applicable to the web platform itself.
You are underestimating the appeal and intellectual stimulation gotten from learning something new regardless of merit.
It's not utter nonsense. I've seen it happen time and again in multiple jobs.
Right now at my current employer "we" are about to embark on replacing our entire data pipeline with a very popular queuing system designed to process hundreds of GB or more of data per day. Our current pipeline moves a few tens to hundreds of MB per day (not second, minute or hour) from the point of intake to our internal data stores. There are two reasons as I see it for the choice: resume driven development by the "architect" who proposed it (and management who want to put the management portion on their resumes) and laziness to address other issues regarding why there are delays at certain points in the pipe.
You by your own admission have no idea what the architect was thinking and the motivations behind the design. There could be plenty of reasons such as additional future data sets or design decisions that you simply aren't privy to. Or often the reason is related to non functional requirements for example the fact that most companies live and die by enterprise support.
Before criticising something as "resume driven development" it might be better to actually have a detailed conversation first.
I know enough of the current data pipeline and strategic roadmap to know that the proposed solution is overkill for the foreseeable future and doesn't actually address the underlying problems. Just because he's the architect doesn't mean everyone else is an inexperienced junior individual contributor.
Comments
Utter nonsense.
Developers use these frameworks (a) because they like it, (b) because there is a wealth of knowledge on the internet about how to fix every little problem, (c) because it allows them to be productive with their peers and (d) because often they learn something new. People get bored doing the same thing over and over again for 30 years like you seem to be advocating for.
Imagine going to a doctor and getting a prescription because "they like it".
Let's hope they're using the same version you're using.
Productivity without a framework must be impossible...
They learn something about the framework at the present time, which may be worthless after the next breaking change, and is not generally applicable to the web platform itself.
You are underestimating the appeal and intellectual stimulation gotten from learning something new regardless of merit.
I have some very troubling news for you...
It's not utter nonsense. I've seen it happen time and again in multiple jobs.
Right now at my current employer "we" are about to embark on replacing our entire data pipeline with a very popular queuing system designed to process hundreds of GB or more of data per day. Our current pipeline moves a few tens to hundreds of MB per day (not second, minute or hour) from the point of intake to our internal data stores. There are two reasons as I see it for the choice: resume driven development by the "architect" who proposed it (and management who want to put the management portion on their resumes) and laziness to address other issues regarding why there are delays at certain points in the pipe.
You by your own admission have no idea what the architect was thinking and the motivations behind the design. There could be plenty of reasons such as additional future data sets or design decisions that you simply aren't privy to. Or often the reason is related to non functional requirements for example the fact that most companies live and die by enterprise support.
Before criticising something as "resume driven development" it might be better to actually have a detailed conversation first.
I know enough of the current data pipeline and strategic roadmap to know that the proposed solution is overkill for the foreseeable future and doesn't actually address the underlying problems. Just because he's the architect doesn't mean everyone else is an inexperienced junior individual contributor.