use modules within it for undreamed of purposes and fix it when it goes bad (and it will go bad). Unless it is allowed for in the initial design and implementation you will pay far more to "retro-fit" maintainability

By your own words, the things that will need changing are "undreamed of".

So all the effort you put in at the beginning to cover off all the possibilities that you can dream of--95% of which will never be needed--is wasted effort. And you won't have thought of the undreamed of things that are needed.

But it is almost always worse than that. All the complexity you added trying to facilitate all those things you predicted (guessed) might be needed, but never will, will make the adaptation to the one thing you didn't dream of 10 times harder.

So, now you wasted time and money up front, and it costs you 2x, 5x, ... more to make the change once you actually know what that change is.

Predicting the future is a mug's game. And the more obvious the future you predict seems to be, the harder you will be bitten and the more it will cost you when it doesn't come true.

More money has been wasted, more projects scrapped before they ever saw production, and more good money thrown after bad in the software industry because of whatifitis, and its close cousin, wouldntitbeniceifitis, than all other causes combined. And that includes crude, naive and just plain badly written code.

From experience, it is far easier to maintain, re-factor and upgrade simple, but crude code than it is to so for nicely structured but heavily nested O'Woe code written to try and cater for every possible future.

With the former you know that what code there is serves a useful purpose, even if it gets it wrong sometimes. With the latter, your first task is to try to work out what of the morass of code is actually ever exercised by real workloads, before you can begin the process of correcting its flaws or adapting it to new requirements.

Simple is always best. Even if you think something might be required at some point. Don't add it until is is required. Because you can bet your bottom dollar, that often it won't be required, but will get in the way of what actually is.