3 ms·

Curiously, this doesn't include the most common reasons I've seen: 1. Because we our engineers don't know X, and we wouldn't be able hire people who already kn

Curiously, this doesn't include the most common reasons I've seen: 1. Because we our engineers don't know X, and we wouldn't be able hire people who already know X. 2. Because we are already invested in Y, and the benefits of X are nebulous and speculative, or can't be connected clearly to business outcomes. In essence, both of these come down to a matter of organizational inertia, but that inertia can either be good or bad. A lot of times, organizations don't really have a process to proactively evaluate technology, and the process for making technology changes is ad-hoc. Even when there is a clear need to make a change, it's not clear who all the stakeholders are or who makes the final decision. Ideally this is something that should be sponsored by senior technical leaders (CTO, VPE, etc) but the decisions should be made by your most senior, boots-on-the-ground technologists. (Or you can just individuals/teams to use whatever tech they want, with thr understanding that they have to be good citizens with regards to maintenance, documentation, tooling, etc.)

random314 5y ago
+10
Thorentis 5y ago
Yeah, I suspect the most common reason is some version of "we have already spent millions on hiring people with experience in x, and it would be too expensive to refactor and use y". Sometimes the best tool is the one you already own and use.
- bruce511 5y ago
  A million times this. I use x. Y exists. When someone pitches y to me, I'm happy to stipulate that y is better. (it is, or isn't, but that doesn't matter, so I'm happy to concede/ignore that point.) The question is, will Y compile all my existing code? Since the answer to that is no you are suggesting either A) we rewrite existing code in Y. Or B) we add resources enough to build new stuff in y while maintaining the existing in x. That becomes an economic question not a technical one. Also what happens when all my highly qualified, experienced, and proficient X leave (cause their careers just came to a dead end) and in left with the thing we actually sell and no one to support it? Swapping y for x sounds like a technical decision, but is far more an economic /existential decision for some part of the business [1]. [1] I'm not talking about the small stuff here - we can easily swap out a text editor, but changing a language or in some cases a database is a big deal.
ufmace 5y ago
Yup, in a corporate environment, it's often a very rational reason to say, we already know X. The full meaning is, we have a bunch of stuff built in it, we have a dozen experts on it on staff, we have hiring and training pipelines for it, we have a bunch of standard tools built around it, etc. Even if Y is legitimately better, switching is very expensive and time-consuming. Just trying Y doesn't help much, if we do anything significant with it, then we have to double our efforts in keeping experience with X and Y in house, keeping tools compatible with both, keeping watch on security updates for both, etc. It's pretty rare for such switches to ever generate any business value.
EdwardDiego 5y ago
Indeed. X might be the hyped up flavour of the day, but if you've got large codebases and/or workflows based on Y, then changing to X is a) non-trivial and b) X may not solve the problems as well as Y. As an example from my experience, when Apache Spark became popular (around v1.8), there were a fair few people in certain circles sneering at Hive, clearly Spark was superior because you could cache intermediate results to RAM. Except Spark at the time (I haven't used it in anger since v2.2) was rather terrible at the very large datasets Hive could grind through with no issue. Sure, Hive was slower, but then it had the distinct advantage on very large datasets of not dying with an OOM error 2 hours into a job.

random314 5y ago

+10

Thorentis 5y ago

Yeah, I suspect the most common reason is some version of "we have already spent millions on hiring people with experience in x, and it would be too expensive to refactor and use y". Sometimes the best tool is the one you already own and use.

bruce511 5y ago
A million times this. I use x. Y exists. When someone pitches y to me, I'm happy to stipulate that y is better. (it is, or isn't, but that doesn't matter, so I'm happy to concede/ignore that point.) The question is, will Y compile all my existing code? Since the answer to that is no you are suggesting either A) we rewrite existing code in Y. Or B) we add resources enough to build new stuff in y while maintaining the existing in x. That becomes an economic question not a technical one. Also what happens when all my highly qualified, experienced, and proficient X leave (cause their careers just came to a dead end) and in left with the thing we actually sell and no one to support it? Swapping y for x sounds like a technical decision, but is far more an economic /existential decision for some part of the business [1]. [1] I'm not talking about the small stuff here - we can easily swap out a text editor, but changing a language or in some cases a database is a big deal.

ufmace 5y ago

Yup, in a corporate environment, it's often a very rational reason to say, we already know X. The full meaning is, we have a bunch of stuff built in it, we have a dozen experts on it on staff, we have hiring and training pipelines for it, we have a bunch of standard tools built around it, etc. Even if Y is legitimately better, switching is very expensive and time-consuming. Just trying Y doesn't help much, if we do anything significant with it, then we have to double our efforts in keeping experience with X and Y in house, keeping tools compatible with both, keeping watch on security updates for both, etc. It's pretty rare for such switches to ever generate any business value.

EdwardDiego 5y ago

Indeed. X might be the hyped up flavour of the day, but if you've got large codebases and/or workflows based on Y, then changing to X is a) non-trivial and b) X may not solve the problems as well as Y. As an example from my experience, when Apache Spark became popular (around v1.8), there were a fair few people in certain circles sneering at Hive, clearly Spark was superior because you could cache intermediate results to RAM. Except Spark at the time (I haven't used it in anger since v2.2) was rather terrible at the very large datasets Hive could grind through with no issue. Sure, Hive was slower, but then it had the distinct advantage on very large datasets of not dying with an OOM error 2 hours into a job.