Collective Wisdom from the Experts 85
Bugs will remain part of every software product shipped. We put bugs into
software for both bad reasons (like ignorance of language features or poor
attention to detail) and good ones (such as conflicting or poorly communi-
cated requirements). Further, bugs are a source of change in software because
when they are recognized we refactor the code to fix them, injecting new bugs
in the process.
Meir (Manny) Lehman was the first to recognize that software evolves dur-
ing its life cycle, way back in 1969. He later figured out that multiple feed-
back loops exist within a software development effort, and that those feedback
loops influence the process of evolution. They include the injection of multiple
(possibly conflicting) requirements and design decisions.
Various degrees of programmer understanding of requirements, design deci-
sions, and implementation details contribute to other feedback loops. In other
words, the sources of bugs don’t have to be logical programming errors. Bugs
are also introduced by differences of opinion.
The Fallacy Of Perfect Execution is the delusion that it is possible to create
flawless code with sufficient attention to detail. If that were so, we would all
be strong advocates of structured programming techniques. We aren’t, and for
good reason. Software, at any stage of its evolution, is buggy, extremely likely
to change, and inaccurately documented.
That insight, simple though it may be, encourages us to approach software
differently. It encourages us to develop tools and techniques to incrementally
refactor software implementations, requirements, and documentation.