That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time.
Also, it is way too expensive to try to cover every single conceivable possibility, so we deliberately leave holes.
For non-trivial things we often prefer to wait to see what problems actually come up during use, and then fix exactly those, but not the many more problems that could come up but are too unlikely and/or too costly to guard against.
In a living environment the software lives too, and keeps changing and adapting.
you might've missed the quip, since this whole thread is about a quote, which i'm countering with an alternative quote from Hoare
> There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.
> That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time.
It sounds to me like you are describing a change of problem, not bugs in the solution. If in the future someone redefines the concept of a Sudoku puzzle such that this solution is no longer applicable, or tries to use the solution verbatim in a language which is different from K and therefore yields different results, it's not a bug in the original code that it's not a solution to that new problem. It's still a solution to the same problem it was always a solution to.
I can see what you mean in a practical sense, but also consider (practically) that a lot of problems can be broken down into smaller, well-defined problems which are themselves practically immutable. You can throw the solutions to such problems out when you no longer need them, and come up with solutions to whatever new problems replaced the original problems.
In my experience, the vast majority of problems are insufficiently specified. No matter how well you solve the current problem, there are bound to be certain assumptions you've made about the requirements. And when those assumptions don't hold true, your solution may no longer work.
> What do you mean the input file can't be ISO-2WTF encoded?
Debugging problems is part of maintenance, but a small part. Extensibility is probably a much larger part, and what I think of first when someone says "maintenance".
By being so smart that your program has obviously zero bugs in it!