Different Types of Software Myths

Management Software Myths

The manager who is responsible for developing software is often under pressure regarding many attributes of the software such as:

• The budget of the software.
• Delivering the software within the time limit.
• Enhance the quality of the software.
• Providing customer care services, etc.

Under such pressure, even the software manager develops belief in a software myth that lessens. These software myths grasped by the software manager lessen his pressure up to a certain level but this is temporary.

Let us discuss some myths perceived by the software manager:

• Management Myth 1

  The software building team has a book that explains all standards and procedures that are required for developing software.

  The manager has a myth that the book provides everything to the team required for the software development.

  Fact:

  Though there exists a book that has all the standards and procedures required to develop software. But are the developers aware of its existence? Do they ever refer to such books? Is the book complete?

  Can it be referred to? Does the book help the developers to stick to the time-to-deliver even maintain the quality of the software?

  Most of the time the answer to such questions is no.

• Management Myth 2

  If more programmers are added to the software development team we can stick to the schedule.

  Fact:

  Developing software is totally different from manufacturing a product. It is not a mechanistic process. In fact, adding up more people in the team would rather delay the delivery of the software.

  This is because when new members are introduced to the team, the members already working on the software will have to explain the work done till now. This will even reduce the time that has to spend on the development of the software. People can be added, but only under certain circumstances. Individuals who were working must spend time teaching newcomers when more people are added, limiting the amount of time spent on product development activity. People can be added, but only in a well-coordinated and systematic fashion.

  Although more members can be added to the team in a planned and co-ordinate manner.

• Management Myth 3

  Outsourcing the software project to a third party will let the manager relax. The third-party will be solely responsible for the development of the software.

  Fact:

  If the company has outsourced the software project to a third party, it means the company is not aware of the details of the software project. It doesn’t know how to manage and control the software project.

• Management Myth 4

  My workers have cutting-edge software development tools. The addition of the latest hardware programs will improve the software development.

  Fact::

  • The role of the latest hardware is not very high on standard software development; instead (CASE) Engineering tools help the computer, they are more important than hardware to produce quality and productivity.
  • Hence, the hardware resources are misused.

Customer Myths

The customer is one who requests software either from a software engineer, a technical group, or the marketing sales department. The customer always requests the software under a contract.

The customer has some myths regarding the development of software. Hence the customer develops false expectations which lead to dissatisfaction with the developer. Let us discuss some myths developed by the customer.

• Customer Myth 1

  Customers believe that giving a general statement would let the software developer start writing the program. The rest of the details can be filled in later.

  Fact:

  Although it is not possible for a customer to provide a comprehensive and stable statement. And an ambiguous statement will lead to disaster. The unambiguous statement comes with an iterative communication between the customer and the developer. Functions, behavior, performance, interfaces, design restrictions, and validation requirements must all be formalized and explicit.

• Customer Myth 2

  Customers can ask for the changes in software as many times as desired as software is flexible.

  Fact:

  True, software requirements change, but the impact of that change differs depending on when it is implemented. When changes are requested throughout the software development process, the cost effect increases quickly.
  
  The customer can ask for the changes in the software. But the impact of the changes varies from the time it has been introduced. If the customer asks for the changes early during the development of the software the cost impact is less.

  However, over time the impact of changes grows gradually may it be in terms of cost or duration, or the quality of the software.

Practitioner’s Software Myths

Software practitioners are the ones who are involved in the development and maintenance of the software. Earlier developing software is considered as an art. So, the software practitioners have developed some myths regarding the software.

• Practitioner Myth 1

  Once you write the code and develop the software your job is done.

  ✔ Fact:

  Practically 60% – 80% of the efforts are expended on the software when the software is delivered to the customer for the first time.

  When the software is delivered to the customer for the first time. When a customer starts using the software they figure out the improvements that can be made to enhance the quality of the software.

• Practitioner Myth 2

  A successful project is one where the delivered software is working

  ✔ Fact:

  Although the working software is the essential part of software configuration there are many other elements that count in a success of a software project. Such as models of the software, its documents, and plans.

  These are the elements that are essential in the foundation of a successful engineering product.

• Practitioner Myth 3

  Practicing software engineering while developing software will tend you to create voluminous documentation and this will eventually slow down the process of software development.

  ✔ Fact:

  Practicing software engineering will never tend you to create huge documentation instead it focuses on the quality of the developed software. A better-quality software reduces the number of iterations and thus faster the delivery time.

• Practitioner Myth 4

  They believe that their work has been completed with the writing of the plan.

  ✔ Fact:

  It is true that every 60-80% effort goes into the maintenance phase (as of the latter software release). Efforts are required, where the product is available first delivered to customers.

• Practitioner Myth 5

  Our effort is done once we develop the software and get it to run.

  ✔ Fact:

  According to industry statistics, between 60 and 80 percent of all software effort is wasted after it is given to the client for the first time.

• Practitioner Myth 6
  There is no other way to achieve system quality, until it is “running”.

  ✔ Fact:

  Systematic review of project technology is the quality of effective software verification method. These updates are quality filters and more accessible than test.