1.8 Some Misunderstandings about Software Engineering

During the development history of software and software engineering, people formed many habits and cultural considerations. In the following, three main aspects are listed (abstracted from [Pressman2005]):

M—Myths, R—Reality.

Management:

● M1: 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?

● R1: It takes much more than the latest model mainframe, workstation, or PC to do high-quality software development.

● M2: If we get behind schedule, we can add more programmers and catch up.

● R2: Software development is not a mechanistic process like manufacturing. “Adding people to a late software project makes it later.”

● M3: If we decide to outsource the software project to a third party, we can just relax and let that firm build it.

● R3: If an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsources software projects.

Customers: Lead to false expectations (by the customer) and ultimately, dissatisfaction with the developer.

● M1: A general statement of objectives is sufficient to begin writing programs—we can fill in the details later.

● R1: A poor up-front definition is the major cause of failed software efforts.

● M2: Project requirements continually change, but change can be easily accommodated because software is flexible.

● R2: It is true that software requirements change, but the impact of change varies with the time at which it is introduced.

Practitioners: Myths that are still believed by software practitioners have been fostered by 50 years of programming culture. During the early days of software, programming was viewed as an art form.

● M1: Once we write the program and get it to work, our job is done.

● R1: “the sooner you begin ‘writing code’, the longer it’ll take you to get done.” Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time.

● M2: Until I get the program “running” I have no way of assessing its quality.

● R2: One of the most effective software quality assurance mechanisms can be applied from the inception of a project—the formal technical review.

● M3: The only deliverable work product for a successful project is the working program.

● R3: A working program is only one part of a software configuration that includes many elements.

● M4: Software engineering will make us to create voluminous and unnecessary documentation and will invariably slow us down. Or Software Engineering is merely about documentation.

● R4: 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. All the documents are necessary for improving team communications and quality.