I didn't read the whole article, and that's certainly one way of looking at it. Here is another. That lack of maintainability and flexibility in a core codebase will leave your system in what's essentially cement shoes. Your team will have painted themselves in a corner and things that take hours or days in a nimble team with a nimble codebase will take weeks or months. That's fine most of the time if you're established in your industry, raking in the cash. That is until your industry pivots, and it will pivot. When it does, your team will not be able to pivot and will be included in the "out of business" companies mentioned above.
You don't have to have every algorithm tuned to computer's science's optimal guidance, you just have to have a maintainable system that can adjust to the business environment. I've been at plenty of large companies that can't adapt by adding new features because all the original programmers left, and management is to scared to touch the system for good reason, the codebase is a horrendous, unmaintainable mess.
That only works under the assumption that you have time to come back to it. I've also seen cases where you just get 15 years of cruft, good intentions and bad implementations, at which point people never want to touch it again, because the last time they did they accidentaly broke a client's system.
There's a 6-month startup phase in just about every SW project I've led that sets a strong course for the lifetime of the project that is awfully hard to correct, both for better or for worse. My advice is always suck it up early and collect the dividends down the road.
Make it work, make it right, make it fast.
I've shared that with a couple teams in the past, and it always catches on.
Even though the future is unpredictable, we can at least be clear on where we are going.
