I've been thinking along similar lines for quite a while, you really did a nice job of laying it all out and making it coherent though. I've bookmarked your ess

I've been thinking along similar lines for quite a while, you really did a nice job of laying it all out and making it coherent though. I've bookmarked your essay for future reference. Something that doesn't get talked about too much, that I worry about, is the massive amount of duplication of work effort that happens as a result of this hyperchurn in software architectures. For an industry that relies on terms and phrases like "NIH" and "premature optimization" and "great programmers reuse" to emphasize the importance of productivity, a huge amount of effort is spent every year building out libraries and frameworks and languages to replace previous libraries and frameworks and languages that largely did the same thing. Probably the finest example of this is is CPAN. Perl still has one of the largest community-managed repository of libraries of any other language (probably C or C++ or similar has got it beat). Any software developer in 2015 that decides Perl is just too antiquated to use and wants to move a large Perl codebase to, say, Node.js, now has to either rewrite those libraries or find libraries that have already been rewritten by someone else. If Node (for example) were the only major new language since Perl, I could see how maybe the initial investment in effort to duplicate all of Perl's functionality might pay off if Node offers a significant enough improvement in productivity in the long term. But, since Perl there's been PHP, Python, Ruby, Node, Go, to name a few, and each of those have had their own competing frameworks ... we simply aren't gaining enough in long-term productivity when each new language or framework is being replaced within a couple of years by another new language or framework. I have a hunch that a lot of this is a result of a competitive software developer job market. Newer and younger developers, lacking the background and experience of older greybeards, migrate towards newer technologies as a way to differentiate themselves. They eventually get hired into management roles (in startups, this can happen very quickly), where they have the freedom to operate their own fiefdoms, and they quickly establish rules of software architecture that ensure they get to hire other young developers that are comfortable with the latest trend. It can seem a little bit absurd, but fortunately I'm not seeing many signs that this is happening that much yet outside of the HN & startup microcosm.