Collective Wisdom from the Experts 95
such as the spiral or agile methodologies. Iterative development is seen as the
key to delivering a software project encoding “final” requirements. Unfortu-
nately for adherents of those methodologies, delivery of a software project is
just a comma in development, not a period.
Requirements, even when “agreed” upon in detailed upfront design, will
change during development. It is impossible to know them all in advance.
Multiple requirements often result in inconsistencies, even when they are
gathered from a single source. Requirements may even mean different things
to different people. Differing interpretations may be due to perception, goals,
or language. In order to create a successful software project, we must accept
and even embrace these ideas. We do not know it all and we never will.
The Fallacy of Perfect Knowledge is the delusion that it is possible to capture
complete, nonconflicting requirements for a software project. The reality is
that requirements will never be fully known at any time during a software
project’s life cycle—not during analysis, development, maintenance, or even
(or especially) when the system becomes legacy.
Continuous use of the agile techniques of iteration and refactoring into the
maintenance phase of the software life cycle begins to address some of these
concerns. A fuller understanding of the ways that software evolves may be the
next step. Until we have those conceptual tools, use them daily, and accept
our ignorances big and small, we will continue to fall victim to the Fallacy of
Perfect Knowledge.