Page 43 -

14 PART ONE THE PRODUCT AND THE PROCESS

FIGURE 1.3 60–100×
The impact of
change

Cost to change

1.5–6×
1×

Definition Development After release

Practitioner's myths. Myths that are still believed by software practitioners have
been fostered by 50 years of programming culture. During the early days of software,
programming was viewed as an art form. Old ways and attitudes die hard.
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 ([LIE80], [JON91], [PUT97]) 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
Whenever you think,
we don’t have time for applied from the inception of a project—the formal technical review. Software reviews
software engineering (described in Chapter 8) are a "quality filter" that have been found to be more effec-
discipline, ask yourself: tive than testing for finding certain classes of software defects.
“Will we have time to
do it over again?” 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. Documentation provides a foundation for successful engineering
and, more important, guidance for software support.
Myth: Software engineering will make us create voluminous and unnecessary doc-
umentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creat-
ing quality. Better quality leads to reduced rework. And reduced rework results in
faster delivery times.
Many software professionals recognize the fallacy of the myths just described. Regret-
tably, habitual attitudes and methods foster poor management and technical practices,
even when reality dictates a better approach. Recognition of software realities is the
first step toward formulation of practical solutions for software engineering.