The article skims over the fact that a lot of "fix later" problems will never have to be fixed. They might be horrible hacks, but then time will show that no ot

The article skims over the fact that a lot of "fix later" problems will never have to be fixed. They might be horrible hacks, but then time will show that no other code will depend on it and it works. The mongodb example he takes is also peculiar. If it was a "fix later", as I understand the article they should have replaced mongo with a relational database very early on. That might also have tanked the company, if they then had to spend their time fighting schemas. If you commit a "fix it later" hack into the codebase, you need to put a comment in the code and explain what's wrong with it. That'll increase the chances that people at least know about your hack code before they start depending on it. It's expensive to fix problems that don't need to be fixed. But then again, it can also be an order of magnitude (or two or three!) more expensive to not fix a problem that should have been fixed. Just felt the need to rant about it now, because I wouldn't do it later :)