Computer Notes

Header Right

Home » Software Engineering » Software Myths : What is software myth in software engineering.

Software Myths : What is software myth in software engineering.

By Dinesh Thakur

The development of software requires dedication and understanding on the developers’ part. Many software problems arise due to myths that are formed during the initial stages of software development. Unlike ancient folklore that often provides valuable lessons, software myths propagate false beliefs and confusion in the minds of management, users and developers.

Managers, who own software development responsibility, are often under strain and pressure to maintain a software budget, time constraints, improved quality, and many other considerations. Common management myths are listed in Table.

                                                 Table Management Myths

  • The members of an organization can acquire all-the information, they require from a manual, which contains standards, procedures, and principles;
  • Standards are often incomplete, inadaptable, and outdated.
  • Developers are often unaware of all the established standards.
  • Developers rarely follow all the known standards because not all the standards tend to decrease the delivery time of software while maintaining its quality.
  • If the project is behind schedule, increasing the number of programmers can reduce the time gap.
  • Adding more manpower to the project, which is already behind schedule, further delays the project.
  • New workers take longer to learn about the project as compared to those already working on the project.
  • If the project is outsourced to a third party, the management can relax and let the other firm develop software for them.
  • Outsourcing software to a third party does not help the organization, which is incompetent in managing and controlling the software project internally. The organization invariably suffers when it out sources the software project.

In most cases, users tend to believe myths about the software because software managers and developers do not try to correct the false beliefs. These myths lead to false expectations and ultimately develop dissatisfaction among the users. Common user myths are listed in Table.

                                                    Table User Myths

  • Brief requirement stated in the initial process is enough to start development; detailed requirements can be added at the later stages.
  • Starting development with incomplete and ambiguous requirements often lead to software failure. Instead, a complete and formal description of requirements is essential before starting development.
  • Adding requirements at a later stage often requires repeating the entire development process.
  • Software is flexible; hence software requirement changes can be added during any phase of the development process.
  • Incorporating change requests earlier in the development process costs lesser than those that occurs at later stages. This is because incorporating changes later may require redesigning and extra resources.

In the early days of software development, programming was viewed as an art, but now software development has gradually become an engineering discipline. However, developers still believe in some myths-. Some of the common developer myths are listed in Table.

                                                 Table Developer Myths

  • Software development is considered complete when the code is delivered.
  • 50% to 70% of all the efforts are expended after the software is delivered to the user.
  • The success of a software project depends on the quality of the product produced.
  • The quality of programs is not the only factor that makes the project successful instead the documentation and software configuration also playa crucial role.
  • Software engineering requires unnecessary documentation, which slows down the project.
  • Software engineering is about creating quality at every level of the software project. Proper documentation enhances quality which results in reducing the amount of rework.
  • The only product that is delivered after the completion of a project is the working program(s).
  • The deliverables of a successful project includes not only the working program but also the documentation to guide the users for using the software.
  • Software quality can be assessed only after the program is executed.
  • The quality of software can be measured during any phase of development process by applying some quality assurance mechanism. One such mechanism is formal technical review that can be effectively used during each phase of development to uncover certain errors.

You’ll also like:

  1. Software Engineering – What is Software Engineering? Write Basic Objective and Need for Software Engineering
  2. Definition of Software Engineering and Software Engineering Layers
  3. Principles of Software Design & Concepts in Software Engineering
  4. Software Design Reviews in Software Engineering
  5. Measuring Software Quality in Software Engineering
Like/Subscribe us for latest updates     
About Dinesh Thakur
Dinesh ThakurDinesh Thakur holds an B.C.A, MCDBA, MCSD certifications. Dinesh authors the hugely popular Computer Notes blog. Where he writes how-to guides around Computer fundamental , computer software, Computer programming, and web apps.

Dinesh Thakur is a Freelance Writer who helps different clients from all over the globe. Dinesh has written over 500+ blogs, 30+ eBooks, and 10000+ Posts for all types of clients.


For any type of query or something that you think is missing, please feel free to Contact us.