A business requirement I often hear when designing software is that the application must be flexible and easy to change without additional programming. This seems like a sensible idea - we all know that nothing stays the same, and flexibility can make the software continue its usefulness despite changing business conditions, regulations, and standards.

There are two challenges with this requirement. One challenge is that flexibility is a very vague term. For some users, flexibility means that they can customize the colors or menu text. For others, flexibility means the ability to create custom business rules or reports. And for some people, flexibility means all this and more - their lofty ideas of flexibility become a notion of an infinitely malleable system that can be changed any way at any time by anyone.

Which brings us directly into the second challenge: the resulting cost associated with flexibility. The obvious cost is in time and money. Creating a more flexible system will take more time to build, and hence will also ultimately cost you more. There are also hidden costs. Building flexibility into a system can affect system performance. It will also make things more complex, making changes more costly to design, program, test, and fix.

When thinking about system flexibility, you should:

• Consider carefully what you mean by flexibility. Identify those things which are likely to change vs. things that are less likely to change.
• Weigh the consequences. Consult your developer or some other system professional. Take the time to prototype some options, checking the performance when you add a significant quantity of data.
• Be realistic. It might be nice for users to be able to define reports on the fly, but you might learn after consulting with them that most of them really want the same thing anyway, and it doesn't really change. Flexibility might not really be the required feature you think it is.