The document discusses several common myths about software engineering. It presents myths such as the idea that requirements can easily be changed, that adding more programmers will solve scheduling problems, and that coding is the major effort. For each myth, it provides the reality, such as how requirement changes often degrade software, coordination gets harder with more programmers, and coding is usually only 10% of the effort while other post-delivery activities account for 50-70% of the work. The document advocates for formal reviews, documentation, and a team approach rather than relying on individuals.

1. Software Engineering
Software Myths
Lecture # 4

2. Software Myths
 Myth: It’s in the software. So, we can easily change it.
 Reality: Requirements changes are a major cause of software
degradation.
 Myth: We can solve schedule problems by adding more programmers.
 Reality: Maybe. It increases coordination efforts and may slow things
down.
 Myth: While we don’t have all requirements in writing yet, we know
what we want and can start writing code.
 Reality: Incomplete up-front definition is the major cause of software
project failures.

3. Software Myths
 Myth: Writing code is the major part of creating a software product.
 Reality: Coding may be as little as 10% of the effort, and 50 - 70% may
occur after delivery.

4. Software Myths
 Myth: I can’t tell you how well we are doing until I get parts of it running.
 Reality: Formal reviews of various types both can give good information
and are critical to success in large projects.
 Myth: The only deliverable that matters is working code.
 Reality: Documentation, test history, and program configuration are
critical parts of the delivery.
 Myth: I am a (super) programmer. Let me program it, and I will get it
done.
 Reality: A sign of immaturity. A formula for failure. Software projects
are done by teams, not individuals, and success requires much more than
just coding.