Software Myths — Definition & Types

Definition

Software myths are misleading, erroneous beliefs about software and the software process that have been propagated over the years. They can cause serious problems because they set unrealistic expectations and encourage bad practices — for management, customers, and developers alike. They are dangerous precisely because they "sound reasonable."

Types of Software Myths (Pressman's classification)

1. Management myths (believed by managers)

• "We already have a book of standards and procedures for building software — that's all my people need." — Standards without a proper, well-defined process don't guarantee quality.
• "If we get behind schedule, we can add more programmers and catch up." — Adding people late to a project often slows it down (communication overhead, re-training) — the "Mythical Man-Month" effect.
• "We can outsource/copy and adapt software from another project, so it will be cheap and quick." — Software is rarely that portable; adapting external software still requires full engineering.

2. Customer myths (believed by customers)

• "A general statement of objectives is enough; you (developers) can fill in the details later." — Ambiguous requirements lead to the wrong product; detailed requirements must be agreed before design.
• "Software requirements change continuously, but change is easy to absorb." — The cost of change grows steeply as the project progresses; changes are cheapest early and very expensive late.

3. Practitioner (developer) myths (believed by developers)

• "Once the program is written and 'works', our job is done." — Programs that appear to work may still be full of defects; "working" ≠ correct/reliable/maintainable.
• "Until I get the program running, I have no way of assessing its quality." — Quality (reviews, design assessment) can and must be evaluated from the very first phase.
• "Software engineering is just about producing documentation — it makes the work slower." — The discipline (reviews, testing, planning) reduces overall cost by preventing rework.
• "Testing will make the software reliable." — Testing can find defects but cannot prove their absence; reliability is designed-in, not added by testing.
• "The only deliverable is the working program." — Documentation, models, and specs are essential for maintenance and future evolution.

Why they matter

Each myth, if believed, causes poor decisions: skipping requirements, overstaffing late, treating testing as a safety net, ignoring documentation — all of which inflate cost and destroy quality. Recognizing and dispelling these myths is a first step toward a disciplined software process.

Summary table

Category	Example myth	Reality
Management	"More programmers = faster"	More people late = slower
Customer	"Details can be filled in later"	Late change is very costly
Practitioner	"It runs, so it's done"	Working ≠ correct, reliable, maintainable