SOFTWARE MYTHS
Software myths is erroneous beliefs about software and the process that is used to
build it—can be traced to the earliest days of computing. Myths have a number of attributes
that make them insidious. For instance, they appear to be reasonable statements of fact
(sometimes containing elements of truth), they have an intuitive feel, and they are often
promulgated by experienced practitioners who “know the score.”
1) Management myths: Managers with software responsibility, like managers in
most disciplines, are often under pressure to maintain budgets, keep schedules
from slipping, 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 pressure.
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 practice? Is
it complete? Is it adaptable? Is it streamlined to improve time-to-delivery while still
maintaining a focus on quality? In many cases, the answer to all of these questions is “no.”
Myth: If we get behind schedule, we can add more programmers and catch up
Reality: Software development is not a mechanistic process like manufacturing,
“adding people to a late software project makes it later.” At first, this statement may seem
counterintuitive. However, as new people are added, people who were working must spend
time educating the newcomers, thereby reducing the amount of time spent on productive
development effort. People can be added but only in a planned and well-coordinated manner.
Myth: If I decide to outsource the software project to a third party, I can just relax
and let that firm build it.
Reality: If an organization does not understand how to manage and control software
projects internally, it will invariably struggle when it outsources software projects
2) Customer myths: A customer who requests computer software may be a person
at the next desk, a technical group down the hall, the marketing/sales department,
or an outside company that has requested software under contract. In many cases,
the customer believes myths about software because software managers and
practitioners do little to correct misinformation. Myths lead to false expectations
(by the customer) and, ultimately, dissatisfaction with the developer.
Myth: A general statement of objectives is sufficient to begin writing programs—we
can fill in the details later.
Reality: Although a comprehensive and stable statement of requirements is not
always possible, an ambiguous “statement of objectives” is a recipe for disaster.
Unambiguous requirements (usually derived iteratively) are developed only through effective
and continuous communication between customer and developer.
Myth: Software requirements continually change, but change can be easily
accommodated because software is flexible.
Reality: It is true that software requirements change, but the impact of change varies
with the time at which it is introduced. When requirements changes are requested early, the
cost impact is relatively small.However, as time passes, the cost impact grows rapidly—
resources have been committed, a design framework has been established, and change can
cause upheaval that requires additional resources and major design modification
3) Practitioner’s myths. Myths that are still believed by software practitioners have
been fostered by over 50 years of programming culture. During the early days,
programming was viewed as an art form. Old ways and attitudes die ha
Myth: Once we write the program and get it to work, our job is done.
Reality: Someone once said that “the sooner you begin „writing code,‟ the longer it‟ll
take you to get done.” Industry data indicate that between 60 and 80 percent of all
effort expended on software will be expended after it is delivered to the customer for
the first time.
Myth: Until I get the program “running” I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be
applied from the inception of a project—the technical review. Software reviews are a
“quality filter” that have been found to be more effective than testing for finding
certain classes of software defects.
Myth: The only deliverable work product for a successful project is the working
program. Reality: A working program is only one part of a software configuration
that includes many elements. A variety of work products (e.g., models, documents,
plans) provide a foundation for successful engineering and, more important, guidance
for software support.
Myth: Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creating a
quality product. Better quality leads to reduced rework. And reduced rework results in
faster delivery times.
