> And then we can work on a tabula rasa, clean new technologies, this time with some thought put into it. I'm sorry - that just seems a bit...naive. If "we" d

> And then we can work on a tabula rasa, clean new technologies, this time with some thought put into it. I'm sorry - that just seems a bit...naive. If "we" did as you are saying, twenty years would pass and we'd be having this same conversation again. History is rife with examples of trying to fix things by wholesale rebooting, and people thinking "this time it will be perfect!" ...except it never is. I think engineers of all stripes understand this; we've never seen this (yet...) in industries like aerospace or automobiles, or other kinds of hands-on engineering. For one, if it were done, people would probably die. But mainly, I think, because engineers know that throwing the baby out with the bathwater is a bad idea in general; that the institutional knowledge built into the outputs and practices are worth having in place and examining - both to learn what works right, as well as what doesn't. Your suggestion is akin to a "not invented here" mindset, where rather than using existing frameworks and/or libraries, a developer instead opts to "go at it alone", to prove their implementation is better. Sometimes it is; sometimes it does advance things in a good way. But those tend to be outliers; "your implementation" likely won't be that case. Also, to be honest, many of those "game changing" libraries and such are "built on top of" earlier stuff and package it better (with cleanup and tweaks added too). This isn't to denigrate either; in fact it's part of the process (and also show's why "first mover advantage" can sometimes be a fallacy as well).