Common Misconceptions in Software Engineering, Explained

UPI Study › Courses › Software Engineering › Free lessons › Lesson 1.8 Free with a free account

Common Misconceptions in Software Engineering

Software Engineering · Chapter 1: Foundations of Software Engineering and Process ModelsSection 1.8 · lesson 8 of 1037 min · free with a free account

← Walking Through the Systems Development Life CycleNext lesson: The Waterfall Approach: Structure, Strengths, and Use Cases →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

The software myths held by managers, customers, and practitioners - and what really happens.

  • Explain why intuitions from physical production mislead
  • Describe management myths, including Brooks's Law
  • Describe customer myths about goals and changing requirements
  • Describe practitioner myths about documentation and quality

Transcript

Everything said in the video, section by section (962 words). Read along, or search it.

Foundations of Software Engineering and Process Models

Common Misconceptions

Some of the worst decisions in software projects are not made out of ignorance. They are made because something false felt obviously true. This section looks at the common myths held by managers, customers, and practitioners, and at what really happens when they go unchallenged.

Why Myths Take Hold

Borrowed from the Wrong Domain

Most of what people intuitively know about producing things comes from physical goods, such as buildings, cars, and furniture. Those intuitions are not unreasonable. They are simply borrowed from the wrong domain. Software has no mass, no assembly line, and no fixed shape, so intuitions built on physical production tend to misfire. These false beliefs are called software myths. They are dangerous precisely because they feel like common sense, and are rarely challenged. They cluster by who holds them. Managers believe more people means faster. Customers believe requirements can be frozen early. Practitioners believe documentation is optional.

Management Myth

Adding People to a Late Project

The most persistent management myth is also the most intuitive one. If a project is behind schedule, adding more people should help it catch up. In physical labor, that is often true. More people digging a trench finish faster. Software does not work this way. New team members need time to become productive. Someone already on the project has to stop their own work to bring them up to speed. And the number of communication paths between team members grows faster than the team itself. This pattern is known as Brooks's Law, after Fred Brooks, who observed that adding people to an already-late software project tends to make it later.

Why Coordination Explodes

Every Pair Is a Path

Here is why coordination grows so quickly. Every pair of people on a team is a communication path. Two people share one path. Four people share six. Six people share fifteen. Ten people share forty-five. So doubling a team from five people to ten takes the paths from ten to forty-five, far more than double. Brooks's Law is often stated as absolute, but it is really about timing and ramp-up cost. Adding people early, before a project is behind, does not carry the same penalty. The danger is using them as a late-stage rescue.

Management Myth

Tools and Standards Guarantee Quality

A related management myth is that owning the right tools, and a written standards manual, is enough to guarantee good outcomes. Modern development environments and documented processes genuinely help. But they do not substitute for the judgment and discipline of the people applying them. A book of standards that nobody follows changes nothing.

Customer Myths

Vague Goals, and Free Changes

On the customer's side, the most common myth is that a general statement of goals is enough to start building, with details worked out along the way. In practice, the details are where the real difficulty lives. Two people can agree enthusiastically on a broad goal, and disagree completely once specifics are on the table. Starting on vague goals does not save time. It just moves the disagreement to a more expensive point. A related myth comes in two halves. That requirements can be frozen early for good, or that changing one is always cheap, because it is just software. Both halves tend to be wrong. Requirements naturally shift as stakeholders see early versions, and that is normal, not a planning failure. But the cost of a change is not constant. A change made while the system is still being defined, is far cheaper than one made after design and construction have built on the original assumption.

Practitioner Myths

Running Code Is Not "Done"

Among the people writing software, the most common myth is that once a program runs correctly, the work is essentially done. Documentation gets treated as optional overhead. That feels reasonable. The running program is tangible proof of progress, and a written explanation of design decisions is not. But most software is read, changed, and maintained by people other than its author, often long after that author has moved on. Without documentation, each of them has to reconstruct the reasoning from the code alone, which is slower, and more error-prone. A second myth is that quality cannot really be judged until a program runs. In fact, a poorly scoped problem, a missed constraint, or an inconsistent set of requirements can all be caught by careful review, long before anything executes.

The Myths Side by Side

Why They Feel True

Here are the myths side by side. More people means faster feels true because it works for physical labor. In software, ramp-up and coordination can slow a late project further. Vague goals are enough feels true because broad agreement feels like enough. Real disagreement surfaces later, at higher cost. Late change is free feels true because software has no physical form. But later changes cost more, because other decisions were built on the original assumption. And documentation is optional feels true because the running program feels like the real deliverable. Undocumented systems become expensive and risky to maintain. All of these share one underlying error. Mistaking what feels obviously true for what has actually been verified.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. A software myth is a widely believed, but false, assumption about how software is built, that leads to poor decisions. Brooks's Law says that adding people to an already-late software project tends to make it later still. Requirements volatility is the tendency of requirements to keep changing, as stakeholders learn what they actually need. And documentation is recorded information about a system's design, decisions, and usage, maintained alongside the code.

Key Takeaways

What to Carry Forward

To pull this together. Software myths come from intuitions about physical production, applied to something that does not work the same way. Brooks's Law warns that late-stage staffing adds ramp-up time and coordination overhead, making a late project later. Tools and standards help only when people actually apply them well. Vague goals only defer disagreement, and while requirement change is normal, its cost rises the later it comes. And running code is not the finish line. Documentation and early review are part of the work.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Common Misconceptions in Software Engineering

What is Brooks's Law?
Brooks's Law, named after Fred Brooks, says that adding people to an already-late software project tends to make it later. New team members need time to become productive, existing members must pause their own work to bring them up to speed, and communication paths grow faster than the team. The law is really about timing and ramp-up cost; adding people early carries less of a penalty.
How many communication paths does a software team have?
A team of n people has n(n-1)/2 communication paths, because every pair of people is one path. Two people share one path, four share six, six share fifteen and ten share forty-five. Doubling a team from five to ten people takes the paths from ten to forty-five, which is why coordination overhead grows much faster than headcount.
What are common customer myths about software requirements?
A common customer myth is that a general statement of goals is enough to start building, with details settled later. In reality, people who agree on a broad goal often disagree once specifics appear, so vagueness just moves the conflict to a costlier point. Another myth is that requirements can be frozen early for good, or that changing them is always cheap because it is just software.
Is software finished once the program runs correctly?
No. Believing running code means the work is done is a common practitioner myth. Most software is read, changed and maintained by people other than its author, often long after that author has moved on, and without documentation they must reconstruct the reasoning from code alone. Quality also need not wait for execution: poor scoping, missed constraints and inconsistent requirements can be caught by careful review.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →