Beyond Code

Flexibility vs. Simplicity

In each case we trade simplicity vs. flexibility. It seems like a fair deal - what we loose on the one side, we gain on the other. Furthermore, common lore suggests that flexibility is good. Nobody wants to be locked in to a single database vendor. And since it appears to be a fair deal, it is safer to err on the side of too much flexibility.

Only it isn't a fair deal. What we fail to take into account is that the price (in terms of additional complexity) must be paid now, while the expected benefit (in terms of higher flexibility) might never be reaped! In the case namely, that none of those planned for changes are ever made.

How likely is it really that we will change our database vendor? That is a question that each project will have to answer individually. If the project team has done sufficient up-front research and evaluation (as it should), the answer may very well be: not very. In other cases, in particular where forces outside of the actual project may be significant (for instance in large corporate settings, where decisions may be made at the spur of a moment for political, rather than technical reasons), the likelihood of such changes may be considerable. Designing for change may very well be crucial in such a situation.

Clearly, there is a wide continuum in the environment that each project exists in, from highly volatile or even unpredictable, to quite stable and foreseeable. In the same way, there exists a continuum in the degree of flexibility than can be built into the system. In any case, there should be enough flexibility to provide a sufficient hedge against the risk of change. Flexibility is like insurance: the price has to be paid regardless, but you may never see the benefit of it.

First footnote: The suggestion to build only as much software as is needed to fulfill the current (as opposed to perceived future) requirements is also made by proponents of the Extreme Programming (XP) methodologies. On the other hand, the Extreme Programming movement de-emphasizes up-stream activities in general, relying instead on the agility to react rapidly if things change. But what happens if the recommendation to build as little software as necessary collides with recommendation to be open to change? I have not seen topics such as technology selection and environment analysis addressed in the literature on XP. In any case, the approach suggested here is quite different from the one proposed by XP: we suggest that you can dispense with additional complexity - but only if you have done sufficient up-stream analysis and planning.

Second footnote: Since architectural flexibility is like insurance, it brings with it a pathology known from the insurance business: morale hazard. In insurance terms, morale hazard is a condition that exists when a person is less careful because of the existence of insurance. When a system is designed in such a way as to avoid committing to any particular design as much as possible, there is a real risk that the development will never converge. At any real or perceived difficulty the grass-is-greener syndrome suggests to "just replace" the offending module. A project can be kept spinning literally forever, while ever new approaches are being tried out.