Software myths are the beliefs that people consider are true but are not, regarding software and its development process. The software myths have been carried over several years and are now identified by software engineering professionals.
The managers and software practitioners are habitual to these myths. However, the old habits are difficult to modify.
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:
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.
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 answer to such questions is no.
If more programmers are added to the software development team we can stick to the schedule.
Developing is 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 from the time that has to spend on the development of the software.
Although more members can be added to the team in a planned and co-ordinate manner.
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.
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.
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 customer develops false expectations which lead to dissatisfaction with the developer. Let us discuss some myths developed by the customer.
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.
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.
Customers can ask for the changes in software as many times as desired as software is flexible.
Well, 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.
Practitioner’s Software Myth
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.
Once you write the code and develop the software your job is done.
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.
A successful project is one where the delivered software is working
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.
Practicing software engineering while developing software will tend you to create voluminous documentation and this will eventually slow down the process of software development.
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.
In the section above, we have discussed the software myths from the customers’, developers’, and the manager’s point of view. Thus, recognizing the realities of the software will let you formulate some practical solutions.