Everything Changes

-------------------------------
EVERYTHING CHANGES
-------------------------------

Systems are built to satisfy the requirements of users. Successful systems -
a) meet those requirements and,
b) will continue to be used by the users, who would prefer it to any other.

It is possible for a system to succeed even if it is not flexibly designed. My system does the job and they like it! These are the requirements, my system is designed for that! Who cares that it is not flexible! I have done the requirement-collection to perfection. There's nothing more they could possibly want!

Now who wouldn't want his system to be successful? In fact, most people would want their creation to be indispensable! But with great power, comes great responsibility. Good design is all the more essential if your system has even the remotest chance of being successful - if you want to be a star, not just a shooting star.

Successful systems will be used by the users and, over a long period of time. Any successful system will, in the course of its lifetime, be required to accommodate changes. No matter how well you did the requirement-collection, over time, the set of users will change and by extension, the requirements too! All of a sudden your "successful" systems becomes a failure. Users choose to switch from the system

We must be able to adapt and quickly at that. Accommodating new requirements or changing the behaviour should not become an unnecessarily complex or time-consuming chore - requiring the complete revalidation of the system. Resilience to change is one of the hallmarks of a good design.

Changes in a system may be required because -
a) The users of the system have new requirements. Wouldn't it be cool if this thing could do that as well?... I want to use my credit-card to pay..... or ... I want this bus to fly!
b) Better, more suitable ways of doing things may emerge only after the system is deployed. Would it not be better and simpler to do it like this?... I want the system to start when I press the end button...
c) There were slight errors in our understanding of the requirement. Largely unavoidable. Because only hindsight is 20/20. Oh, was that the order in which you wanted things to happen?... The person should be given the receipt before he pays....

While bus-to-airbus scenarios are well-nigh impossible to design for, with a little bit of thoughtful design, the other two can be designed for more easily. What's more, often you will find that many of the seemingly bus-to-airbus requirement-changes could have been handled in less cumbersome ways, if only you had thought about possible changes during design.

-Thomas Jay Cubb