The business requirements have changed.
At that point, and at no time before, you have sufficient information available to accommodate that change in requirements.
At any point before that, the expenditure of significant extra effort in an attempt to ease the accommodation of possible future requirements is nothing more than gambling.
When you've been a part of a project that has accumulated over 800 man years of development effort, and then seen it scrapped in its entirety because of an arrogant designer who came in and decided that the project had to anticipate a bunch of future possibilities--some of which were so fanciful that you'd be hard pushed to realise them with today's hardware, let alone the 486 and pentium I processors of the time--that it pushed the first release 6 months and $100 million over budget and still it didn't meet half of the actual requirements. At that point, you get very wary of those who believe they can predict the future.
The bottom line is that until you and others start talking in specifics--actual code samples demonstrating your definition of 'good' and 'bad' code with respect to maintenance--nothing will be resolved.
In reply to Re^7: Legacy Code: "Dominoes = Bad"
by BrowserUk
in thread Legacy Code: "Dominoes = Bad"
by locked_user sundialsvc4
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |