Software Myths : What is software myth in

software engineering.
by Dinesh Thakur

The development of software requires dedication and understanding on the

developers' part. Many software problems arise due to myths that are
formed during the initial stages of software development. Unlike ancient
folklore that often provides valuable lessons, software myths propagate
false beliefs and confusion in the minds of management, users and
developers.

Managers, who own software development responsibility, are often under

strain and pressure to maintain a software budget, time constraints,
improved quality, and many other considerations. Common management
myths are listed in Table.

Table Management Myths

 The members of an  Standards are often

organization can acquire all- incomplete, inadaptable,
the information, they and outdated.
require from a manual,  Developers are often
which contains standards, unaware of all the
procedures, and principles; established standards.
 Developers rarely follow all
the known standards
because not all the
standards tend to decrease
the delivery time of
software while maintaining
its quality.

 If the project is behind  Adding more manpower to

schedule, increasing the the project, which is already
number of programmers behind schedule, further
can reduce the time gap. delays the project.
 New workers take longer to
learn about the project as
compared to those already
working on the project.

 If the project is outsourced  Outsourcing software to a

to a third party, the third party does not help
 management can relax and the organization, which is
let the other firm develop incompetent in managing
software for them. and controlling the software
project internally. The
organization invariably
suffers when it out sources
the software project.

In most cases, users tend to believe myths about the software because
software managers and developers do not try to correct the false beliefs.
These myths lead to false expectations and ultimately develop
dissatisfaction among the users. Common user myths are listed in Table.

Table User Myths

 Brief requirement stated in  Starting development with

the initial process is enough incomplete and ambiguous
to start development; requirements often lead to
detailed requirements can software failure. Instead, a
be added at the later stages. complete and formal
description of requirements
is essential before starting
development.
 Adding requirements at a
later stage often requires
repeating the entire
development process.

 Software is flexible; hence  Incorporating change

software requirement requests earlier in the
changes can be added development process costs
during any phase of the lesser than those that
development process. occurs at later stages. This
is because incorporating
changes later may require
redesigning and extra
resources.

In the early days of software development, programming was viewed as an

art, but now software development has gradually become an engineering
discipline. However, developers still believe in some myths-. Some of the
common developer myths are listed in Table.

Table Developer Myths

 Software development is  50% to 70% of all the efforts

considered complete when are expended after the
the code is delivered. software is delivered to the
user.

 The success of a software  The quality of programs is

project depends on the not the only factor that
quality of the product makes the project
produced. successful instead the
documentation and software
configuration also playa
crucial role.

 Software engineering  Software engineering is

requires unnecessary about creating quality at
documentation, which slows every level of the software
down the project. project. Proper
documentation enhances
quality which results in
reducing the amount of
rework.

 The only product that is  The deliverables of a

delivered after the successful project includes
completion of a project is not only the working
the working program(s). program but also the
documentation to guide the
users for using the
software.

 Software quality can be  ]

assessed only after the
program is executed.