3 ms·
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.wi
by 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 agoIn 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 agoIf 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 agoAWS 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.