After reading the headline, I was actually expecting the article to go in a totally different direction. Most of the time, when I see software with rotten found

After reading the headline, I was actually expecting the article to go in a totally different direction. Most of the time, when I see software with rotten foundations, it's there to preserve backward compatibility. The maintainers all see the rot, they want to fix it, they want to clean it all up, they want to do things right. But they can't do anything that would change the API or break user space in any way, and so, they continue supporting the rot indefinitely. The alternative of course, is to fix the rot and prioritize long term benefits over short-term pain. The downside is that this could break backwards compatibility. This is the path Python chose when they went from Python 2 -> Python 3, and the resulting schism was so great, that they have promised to never do this again. More often than not, this is the same experience that every software project goes through. Breaking backwards compatibility is so disruptive, that even living with a rotten foundation seems preferable. Given the blog title, I would have expected that author to argue that fixing the rot is preferable over almost anything else. Instead, he seems to be making the exact opposite argument. He's making the argument that breaking backwards compatibility is so bad, that we should never do it, no matter how rotten the existing API might be. Of course, he wouldn't actually frame it that way. If you asked the author, he would simply ask "Why can't you just build the API right the first time?" One might as well ask the question: "Why can't you just build a software without any bugs?" Let's see... 1) To err is human and people will make mistakes. Both in implementation (bugs), and in design (bad APIs). 2) Building safeguards against mistakes is expensive, in time and effort. Building 100% robust safeguards against mistakes, is extremely expensive. 3) There's only so much you can learn in a lab, or from a beta. If you don't have any regrets from 2 years of live data, then you haven't learned anything at all. Every project strikes its own balance along the speed vs stability, and improvement vs backwards-compatibility axis. And there is no intrinsically wrong answer. Just because what your ideal balance differs from the balance that the project chose, is no reason to insult and condescend to them. And yelling at someone for being human and making mistakes, just sounds childish more than anything.