3

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.
Pavel Voronin
  • 1,640
  • 1
  • 18
  • 25

1 Answers1

4

I think the key is to encapsulate the sources of likely change within your application.

In a way, change is good as it indicates the software is growing (new requirements) or getting better (bug fixes).

With an understanding of where the change is likely to occur (AKA. "know your business domain") then you can structure the application to encapsulate those areas of change. And I think that's what you're considering when you say localize this cases to understand the implications from the very beginning.

You are still at risk to a catastrophic change (eg. a requirements change that causes a disproportionate amount of code change), but that's always a risk within software development.

Wisdom gained from experience with design and programming is how we know to encapsulate the areas of change. A solid understanding of the current requirements as well as the broader vision of the project is crucial as well. Locking your application vision into a single sprint at a time will increase your risk of catastrophic change. (Good) Agile promotes focusing on the sprint but also understanding the overall direction.