3 ms·

Would you say a groupthink is a possible cause? In the past I've seen developers band behind a specific technical platform or framework without considering the

Would you say a groupthink is a possible cause? In the past I've seen developers band behind a specific technical platform or framework without considering the possible downsides and constraints that were raised by a few individuals. Not even having a conversation around it but "this is how we do things here, we are an X shop". It makes me uneasy when everybody's answer is exactly the same and they arrived it not through individual opinions but by adapting to whatever was set in place. This isn't bad if all options were thoroughly explored or possible pitfalls addressed (there are no absolute, only subjective and relative truths that come with pros & cons which each decision)....but when there won't even be a debate or conversation asking if what we are choosing to use is really the right thing because we thought it through independently or just because some big name at big company X declared it is the new paradigm. After all, we are all fallible, development and tools we use is influenced more by marketing than proper cost/benefit analysis. Whatever seems hip, new, cool tends to triumph. "What? PHP is sooo 2006, we need a React/Redux app for our blog so it will be easy to scale using node.js asynchronity"

zigzigzag 10y ago
I wouldn't describe that as groupthink. Groupthink has a fairly clear definition and set of symptoms, well, clear by psychology standards anyway: https://en.wikipedia.org/wiki/Groupthink https://en.wikipedia.org/wiki/Groupthink What you're describing doesn't have any obvious "out" group in it. I think instead what you're describing is what you'd expect to see in an environment where judging the merits of tools or processes is very hard and requires a lot of experience, which may be lacking. In such an environment it's natural to look to very successful companies and just copy whatever they're doing, even if you don't fully understand it, in the hope that it works out. And sometimes it will. This isn't helped by the massive expansion of the developer workforce over the past decades, the fact that experienced people tend to get promoted up into management where they lose touch with coding and become 'architects' working entirely in the abstract, the fact that it's almost impossible for firms to correctly match team sizes to the amount of work required resulting in frequent periods of either overload or boredom (that then leads to reinvention of the wheel simply to find something interesting to do). And yes, finally, fashion plays way too large a role in things these days. If I had a dollar for every time I read a blog post along the lines of "we had entirely generic serving problem X and we had to pick between Rust, Node or Go", with the far older and more mature .NET/Java stacks not just discarded but entirely unconsidered, I'd be a rich guy. We end up locked in a vicious circle that works against maturity of tools and processes: - Profitable but slow enterprises look at startups, envy their ability to get things done and wonder if it's because of the stodgy old tools/processes they use. - Fast but money-bleeding startups look at enterprises and say "we aren't a stuffy enterprise shop so we'll do whatever cool thing I read about on hacker news the other day" and often end up boxing themselves into a corner with immature tools or business approaches. Eventually they (might) turn into big slow companies themselves, often entailing either a rewrite along the way to use more traditional tools or absurd investments into digging themselves out of technical debt (Facebook's PHP runtime efforts being a case in point)
- brilliantcode 10y ago
  In your opinion, where does the current state of Javascript and it's fractured development tools, processes and frameworks fare against mature stacks? You are totally spot on in that mature stacks don't even make the list. Obviously, new developers are going to be exposed to the new and hip fashion trends while veterans prefer predictability and stability. It keeps me awake at night thinking about who is right. It could be that we are on the eve of a new paradigm where JS dominates the enterprise or we could be seeing another blip on the radar. I do however think that AWS is a definite paradigm shift in how developers work, especially as serverless is gaining momentum but this is more of a devops/serverops shift imo.
  - btilly 10y ago
    If you're putting together something relatively simple, Javascript is a perfectly fine choice. And the fact that front and back end shares a language is a real win. However if, for example, you have a complex site with intermittent performance problems, good luck. This applies whether you are running complex async code in node.js and you're trying to track down the badly coded callback that blocks everything else. It also applies if you have multiple microservices and you're trying to track down which back end service is causing front end requests to be painfully slow 1% of the time. And, of course, I'm waiting for Javascript to have something like the problems that Rails did in 2013 when it was discovered that automatic deserialization of requests allowed remote code execution..in multiple ways. In the case of Rails, you just had to get an updated package. In the case of npm, however, the dependency system means that you won't be able to eliminate the bug without updating the whole toolchain in a way that is very, very hard to do. The problem is that in Javascript, libraries A and B can and often do import different versions of library C. If C has a critical bug, then you can't get rid of it until you've upgraded all three. Now imagine this with hundreds of dependencies, each of which has pinned its dependencies and has not been tested with breaking changes in underlying libraries that they depend on... Every widely used stack eventually has an "upgrade the world" fire drill. That fire drill is going to be very, very messy with Javascript.
  - zigzigzag 10y ago
    AWS is just a fancier form of server outsourcing. It's helpful and progress but doesn't represent a paradigm shift. Great chance for companies to shoot themselves in the foot by wasting lots of money though: http://idlewords.com/talks/website_obesity.htm#heavyclouds http://idlewords.com/talks/website_obesity.htm#heavyclouds Javascript is a mess. Node got traction because it enabled lots of web devs to port their skills to the server side without having to learn new languages. Heck, the web is a mess. We desperately need a better app platform.
gmarx 10y ago
I wouldn't. I also think it is a small subset of projects in which specific technology choices are critical. Also, it seems you are describing to opposing problems, one shop only wants to use the technology it knows (in my opinion this should be the default position) and another in which they mindlessly want to use the latest and coolest. It takes a very knowledgeable manager to tell the rare cases of "we need the latest tech" from "my engineers want to play with the latest tech"

zigzigzag 10y ago

I wouldn't describe that as groupthink. Groupthink has a fairly clear definition and set of symptoms, well, clear by psychology standards anyway: https://en.wikipedia.org/wiki/Groupthink https://en.wikipedia.org/wiki/Groupthink What you're describing doesn't have any obvious "out" group in it. I think instead what you're describing is what you'd expect to see in an environment where judging the merits of tools or processes is very hard and requires a lot of experience, which may be lacking. In such an environment it's natural to look to very successful companies and just copy whatever they're doing, even if you don't fully understand it, in the hope that it works out. And sometimes it will. This isn't helped by the massive expansion of the developer workforce over the past decades, the fact that experienced people tend to get promoted up into management where they lose touch with coding and become 'architects' working entirely in the abstract, the fact that it's almost impossible for firms to correctly match team sizes to the amount of work required resulting in frequent periods of either overload or boredom (that then leads to reinvention of the wheel simply to find something interesting to do). And yes, finally, fashion plays way too large a role in things these days. If I had a dollar for every time I read a blog post along the lines of "we had entirely generic serving problem X and we had to pick between Rust, Node or Go", with the far older and more mature .NET/Java stacks not just discarded but entirely unconsidered, I'd be a rich guy. We end up locked in a vicious circle that works against maturity of tools and processes: - Profitable but slow enterprises look at startups, envy their ability to get things done and wonder if it's because of the stodgy old tools/processes they use. - Fast but money-bleeding startups look at enterprises and say "we aren't a stuffy enterprise shop so we'll do whatever cool thing I read about on hacker news the other day" and often end up boxing themselves into a corner with immature tools or business approaches. Eventually they (might) turn into big slow companies themselves, often entailing either a rewrite along the way to use more traditional tools or absurd investments into digging themselves out of technical debt (Facebook's PHP runtime efforts being a case in point)

brilliantcode 10y ago
In your opinion, where does the current state of Javascript and it's fractured development tools, processes and frameworks fare against mature stacks? You are totally spot on in that mature stacks don't even make the list. Obviously, new developers are going to be exposed to the new and hip fashion trends while veterans prefer predictability and stability. It keeps me awake at night thinking about who is right. It could be that we are on the eve of a new paradigm where JS dominates the enterprise or we could be seeing another blip on the radar. I do however think that AWS is a definite paradigm shift in how developers work, especially as serverless is gaining momentum but this is more of a devops/serverops shift imo.
- btilly 10y ago
  If you're putting together something relatively simple, Javascript is a perfectly fine choice. And the fact that front and back end shares a language is a real win. However if, for example, you have a complex site with intermittent performance problems, good luck. This applies whether you are running complex async code in node.js and you're trying to track down the badly coded callback that blocks everything else. It also applies if you have multiple microservices and you're trying to track down which back end service is causing front end requests to be painfully slow 1% of the time. And, of course, I'm waiting for Javascript to have something like the problems that Rails did in 2013 when it was discovered that automatic deserialization of requests allowed remote code execution..in multiple ways. In the case of Rails, you just had to get an updated package. In the case of npm, however, the dependency system means that you won't be able to eliminate the bug without updating the whole toolchain in a way that is very, very hard to do. The problem is that in Javascript, libraries A and B can and often do import different versions of library C. If C has a critical bug, then you can't get rid of it until you've upgraded all three. Now imagine this with hundreds of dependencies, each of which has pinned its dependencies and has not been tested with breaking changes in underlying libraries that they depend on... Every widely used stack eventually has an "upgrade the world" fire drill. That fire drill is going to be very, very messy with Javascript.
- zigzigzag 10y ago
  AWS is just a fancier form of server outsourcing. It's helpful and progress but doesn't represent a paradigm shift. Great chance for companies to shoot themselves in the foot by wasting lots of money though: http://idlewords.com/talks/website_obesity.htm#heavyclouds http://idlewords.com/talks/website_obesity.htm#heavyclouds Javascript is a mess. Node got traction because it enabled lots of web devs to port their skills to the server side without having to learn new languages. Heck, the web is a mess. We desperately need a better app platform.

gmarx 10y ago

I wouldn't. I also think it is a small subset of projects in which specific technology choices are critical. Also, it seems you are describing to opposing problems, one shop only wants to use the technology it knows (in my opinion this should be the default position) and another in which they mindlessly want to use the latest and coolest. It takes a very knowledgeable manager to tell the rare cases of "we need the latest tech" from "my engineers want to play with the latest tech"