It's often not wise to pay an extra cost *now* just so you *may* save some costs in the future. The time you spend now to make code more maintainable cannot be spend on writing code that generates revenue. That's 10 years of revenue you'd have to compare against the savings of having to deal with harder to maintain code 10 years from now. Now, in some businesses coding for maintainability makes sense; I'm not arguing that. But I take issue with blanket statements - just because it sometimes makes sense, doesn't mean it always make sense.

Around here, and I expect in most (if not all) cases of non-trivial code, "maintenance" starts during development. You don't have to wait 10 years before you suffer from poor maintainability, you don't even have to wait 10 days.

If it is not maintainable, debugging is harder. Adding features (aka development) after a mere weekend is harder. And as such, meeting the deadline is harder.

But what I have... and what I make it my business to deal with... is “ten year old code.”

When a piece of software is “finished,” it doesn’t disappear.   The business requirements that led up to it do not become frozen in stone.   Why, “the web page” has already become “like, so 2009...”

In its day, the code might have been brilliant.   It probably did reflect the technical requirements of its day, the technologies of its day, the best-practices choices of its day.   But even though that was “ancient history” by present standards, the code is still in service.

But I take issue with blanket statements - just because it sometimes makes sense, doesn't mean it always make sense.

Right, but how does your version of maintainable differ from your version of non-maintainable code?

For me it doesn't differ much