Page 41 -

12 PART ONE THE PRODUCT AND THE PROCESS

properly." Rather, the affliction encompasses problems associated with how we
develop software, how we support a growing volume of existing software, and how
we can expect to keep pace with a growing demand for more software.
We live with this affliction to this day—in fact, the industry prospers in spite of it.
And yet, things would be much better if we could find and broadly apply a cure.

1.4 SOFTWARE MYTHS
Many causes of a software affliction can be traced to a mythology that arose during
the early history of software development. Unlike ancient myths that often provide
human lessons well worth heeding, software myths propagated misinformation and
“In the absence of confusion. Software myths had a number of attributes that made them insidious; for
meaningful standards,
a new industry like instance, they appeared to be reasonable statements of fact (sometimes containing
software comes to elements of truth), they had an intuitive feel, and they were often promulgated by
depend instead on experienced practitioners who "knew the score."
folklore.”
Today, most knowledgeable professionals recognize myths for what they are—
Tom DeMarco
misleading attitudes that have caused serious problems for managers and technical
people alike. However, old attitudes and habits are difficult to modify, and remnants
of software myths are still believed.
Management myths. Managers with software responsibility, like managers in most
disciplines, are often under pressure to maintain budgets, keep schedules from slip-
ping, and improve quality. Like a drowning person who grasps at a straw, a software
manager often grasps at belief in a software myth, if that belief will lessen the pres-
sure (even temporarily).

Myth: We already have a book that's full of standards and procedures for building
software, won't that provide my people with everything they need to know?
Reality: The book of standards may very well exist, but is it used? Are software
practitioners aware of its existence? Does it reflect modern software engineering prac-
tice? Is it complete? Is it streamlined to improve time to delivery while still main-
taining a focus on quality? In many cases, the answer to all of these questions is "no."
Myth: My people have state-of-the-art software development tools, after all, we
buy them the newest computers.
Reality: It takes much more than the latest model mainframe, workstation, or PC
to do high-quality software development. Computer-aided software engineering
(CASE) tools are more important than hardware for achieving good quality and pro-
ductivity, yet the majority of software developers still do not use them effectively.
Myth: If we get behind schedule, we can add more programmers and catch up
(sometimes called the Mongolian horde concept).
Reality: Software development is not a mechanistic process like manufacturing.
In the words of Brooks [BRO75]: "adding people to a late software project makes it