Software myths on the other hand are erroneous beliefs about software and the process that is used to build it, which can be traced to the earliest days of computing. The myth refers to the misleading attitudes that have caused serious troubles for managers and practitioners when building software.
Software myths can be classified to 3 (THREE) which are:
1. Management myths
2. Customer myths
3. Practitioner myths
In order for us to be clear about why the myths occur in the first place, I will give an explanation about the complexity of software development requirement analysis first.
From the image above, it clearly states that without good understanding from all of the developer team and the customer, different solution is produced at the end of the development process. Therefore it is really important to do the requirement analysis properly to evade any problems in later stages as there will be more harmful effects.
The first myth that I will tackled is the management myth.
Managers particularly manager of the software department often pressured with constraints such as budgets, staffing and scheduling. Managers often treat the software myth as if by believing the myths will lessen their pressure.
Some common managerial myths stated by Rogher Pressman are:
Myth: We have the state-of-the-art software development tools; after all we buy the latest computers.
Reality: A high tech software development tools does not really help in developing software if the developer team does not know how to operate it and utilize the tools to its full potential. In the end, they might end up spend more time in figuring how to use the tools rather than spending time developing software.
Myth: If we are behind schedule, we can add more programmers to catch up.
Reality: This act might seems promising in the first glance but actually after a while, it does not really help because current programmers will need to spend some time to educate the new programmers about the project and thus reduce the time needed for productive development.
Myth: A good manager can manage any project.
Reality: In a high stake project especially a software project that costs a lot of money, an expert is needed to manage it carefully. To ensure a good project management, developer’s company will need a manager that can manage one thing that he can do adeptly, not a manager that can manage MANY things but he cannot do it adeptly.
By any means, good managers should not be ignorance of the fact that they are the one who manage the project. Therefore they must know all the process of developing the software comprehensively rather than depending on the team members to sort it themselves.
The second myth that I will tackled is the customer myth.
Customer believes myths about software because software managers and practitioners are not very helpful when it comes to correcting misinformation. Customer marvels with their imagination of the desired software but when the outcome is produced, what the customer gets is not what the one they want. Myths led to false expectation and in the end the dissatisfaction always goes to the developer.
Common myths of the customers are:
Myth: A general statement of objectives is sufficient to begin writing programs – we can fill in the details later.
Reality: Having ambiguous statement of objectives in developing software would always results in a very serious problem though getting a very comprehensive and detailed statement of objectives is impossible. Clear-cut statements of objectives are obtained through an effective and continuous communication between customer and developer.
Myth: I know what my problem is; therefore I know how to solve it.
Reality: Customer may know how to solve it. However from developer’s point of view, the way customer wants to solve it may not be as same as the way the developer wants to solve it. Therefore by maintaining good communication between both parties can guarantee that the needs can be met.
This can be seen apparently because the customer does not know the in-depth of software development and they think that it is an easy process.
The third myth which is the last is practitioner myth or others called developer myth.
Myths that are still believed between the software practitioners have span for over 50 years in the programming culture. Negligence seen in developers is that they think they know everything and neglect the irregular of each problem.
Myths that existed in practitioner or developer are:
Myth: If I miss something now, I can fix it later.
Reality: Whenever something is missed, especially in earlier development stage, we should immediately get it done because if one thing is missed and we only notice it in later stage, a very major modification needs to be done and it will consume much time and will become a big problem to the team.
Myth: Until a program is running, there is no way of assessing its quality.
Reality: The myth is very not true because if software is being build using process model called incremental model, the software quality can be assess by checking each completed functionality. This is due to the fact that the development of the software is broken down to increments and each increment is delivering part of the required functionality.
There are also some assumptions that make the myth become more strengthen:
1. All requirements can be pre-specified.
2. Customers are experts at specification of their needs.
3. Customers and developers are both good at visualization.
4. The project team is capable of unambiguous communication.
To wrap this up, we all should know that realities differ from myths. Therefore the myths should be molded into something more solid and has bases. This could be done by working in a more systematic way. Besides, the developer does not only require hard skills like managing and programming skills but they also need soft skills like a good communication skills in order to ensure the success of developing a software system.
References:
1. Geshan Manandhar, SPM student, Prime College
2. Wiki answers
3. Wikipedia
Tom DeMarco
