This question already has an answer here:
I've met the criterion of good system desing as its stability relative to requirements change.
Small req. changes should raise small changes in design.
Yet I have gut feeling that almost for any somewhat complex software system it's possible to state the set of small changes in requirements which causes unacceptable amount of changes in software.
This feeling is based on personal experience though not very great and the fact that schedules are often broken.
Community can argue against this statement in case of strong disagreement.
But the question only has meaning if you agree.
YAGNI principle works well against overengineering and Agile methodology brings it to the whole process of software development: system evolves incrementally and this perfectly conforms to stability concept which I started this post from.
But... If we however agree that there are some instability points shouldn't we localize this cases to understand the implications from the very beginning? And how is it possible if we designs system in agile incremetnal manner?!
P.S. Itneresting part of the dialog with my colleague:
- Nothing is wrong with incremental software development.
- Do you imagine the costs of changing the architecture of Curiosity's firmware after it landed Mars?
- Hey, but the can and changed the firmware!
- Yes, but before that, they had carefully designed this feature. And if not...that would be the point of no return.