Yep, in my experience with my own software, today's "revolutionary, way better designed approach" is tomorrow's "hacky awfulness that needs a revolutionary, way better redesign", ad infinitum. It's much cheaper to accept and incrementally improve an imperfect solution. But I recognize the possibility that this is purely a personal experience and better developers than I really do know "how to do it better".
> better developers than I really do know "how to do it better".
They don't. They're just selling something. Not to say some approaches aren't better than others, it's just the only way to know which approach is really better is to implement the same problem space in both and compare. Anybody telling you that X is better than Y at Z without personally using both X and Y to do Z is just trying to sell you something. Beware.
It's also why the best test when deciding on a programming language or framework is to look at what others have actually created with it.
"It's also why the best test when deciding on a programming language or framework is to look at what others have actually created with it."
To a point. If everyone followed that rule, no one would ever build anything in anything new. At which point, looking at what others have actually created with it would merely be a test of the longevity of the programming language or framework.
