|
> Too many software developers just know the "current thing" without knowing why it is the current thing and the specific issues that caused us to move on from the old thing. This ignorance of the past frequently encourages developers to reinvent an old thing poorly without understanding that not only is it not new but that we stopped doing it in many contexts for good and nuanced reasons. I agree with this, but I also have real frustration that so often, as an industry, I see big pendulum swings along the lines of "that old thing is bad, let's do this new thing that solves many of the problems of the old thing." Except that engineering is usually about balancing tradeoffs, and oftentimes that new thing leaves you with a different set of problems that the old thing fixed in response to the old-older thing. Microservices were probably my best example of this, where companies were frustrated by the issues with monoliths so they said "Aha, microservices solve all those monolith problems", except microservices come with a whole slew of difficulties of their own, which in my opinion are often more difficult to manage than the problems with monoliths. The industry's love for a hot minute when all these NoSql DBs first came out (i.e. around when Mongo came out), only to later find out "Hey, the ACID guarantees in RDBMS transactions are actually pretty essential a lot of the time" is another good example. One bright spot is that I feel like the industry has matured somewhat when it comes to searching for these silver bullets. All frameworks and tech have pros and cons, and when you solve one problem, don't be unaware of the new problems that will create. E.g. sometimes you still see some "Do it all in the cloud!!" vs. "No, you lose control when you do it in the cloud, you should own it all", but I think more commonly you see reasoned responses along the lines of "it depends". |