Software Myths

 1.   Management Myths:

a.   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 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."

b.   If we get behind schedule, we can add more programmers and catch up (sometimes called the Mongolian horde concept).
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 productivity, yet the majority of software developers still do not use them effectively.

c.   My people have state-of-art software development tools, after all, we buy them the newest computers.
Reality: people who were working must spend time educating the newcomers.

d.   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.   A general statement of objective is sufficient to begin writing programs we can fill in the details later.
Reality: poor up-front definition is the major cause of failed software efforts.

b.   Project 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 project schedule and planning will disturb.

3.   Practitioner’s Myths:

a.   Once we write the program and get it to work, our job is done.
Reality: software can be expended after it is delivered to the customer for the first time.

b.   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 formal 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.

c.   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 any elements. Documentation provides a foundation for successful engineering and, more important, guidance for software support.

d.   Software Engineering will make us to create voluminous and unnecessary documentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creating quality. Better quality leads to reduced rework. And reduced rework results in faster delivery times.