Collective Wisdom from the Experts 125
Unfortunately, such strict controls have the unintended side effect of making a
software system less useful to its end-users. Such decisions, often based upon
short-term economics, were greatly responsible for the alienation of infor-
mation technology departments from their user bases in the 1990s and the
subsequent development of smaller, often duplicate, software systems within
business units during that period.
The sands of requirements constantly shift under our feet. Requirements for
software projects change for some very good, and very simple, reasons. First,
they can. Software is a malleable medium. It is generally much more cost effec-
tive to change software than to make equivalent changes to hardware.
Second, users of software most often exist within competitive environments.
They compete with one another and with other organizations. As they struggle
to compete, they turn to the most malleable parts of their systems for new
advantages. Software’s flexibility is enticing.
If we give up on the Fallacy of the Big Round Ball, we can become more com-
fortable with changing requirements and see software malleability for what it
is: a huge advantage that we control. Requirements will change. We will have
to maintain our code. We will have to inject new requirements that will lead to
violations of our designs. That is a feature, as the saying goes, not a bug.
We can design adaptable software, but only if we adapt our thinking first.
Adaptability, flexibility of design, and readiness for change should be the
cornerstones of any new software project.