2 Software Myths

Introduction

Software myths are the propagated misinformation, wrong ideas, wrong opinions and wrong beliefs about software, which appear to be reasonable statement of facts, sometimes containing elements of truth and promulgated by experienced and respected personalities, but they have caused more harm than good. They can be traced to be the cause of software failure or low quality software. There are various software myths, which are promulgated by various groups of people, therefore, they will be classified and discussed based on the group of people that promulgate them. The various classes of software myths are listed below:

1. Management Myths

These are software myths that are promulgated by managers with software responsibility. The following are the various wrong beliefs of software as promulgated by managers with software responsibility:

1. Software managers believe that the books that we have that are full of standards and procedures for building software are all that they need to know in building quality software.

However, the truth is that the books that are full of standards and procedures for building software may exist, but do the people use them? Are softwre practitioners aware of the existence of such books? Do the contents of such books reflect modern software engineering practice?

• Software managers believe that the practitioners of the software that they are managing have state of the art software development tools, all we need to do is to buy for them the newest computers.

However, the truth is that developing high quality software requires more than the best computers. Furthermore, having state of the art software engineering tools does not mean that they are using the tools efficiently.

• Software managers believe that if they are behind schedule, they can employ more programmers to meet deadline.

However, the truth is that software development is not like manufacturing handware products. In software development, adding more people to the latter stage of software development makes it later. This is because time will be required for the old people that are working on the software project to educate the newcomers, thereby reducing the amount of time spent on productive software development.

• Software managers believe that they can outsource the software project to a third part, and relax, so that the firm will build the software.

However, the truth is that if an organisation does not know how to control an internal software project, they will always struggle to manage the project when they outsource it.

1. Customer Myths

These are the software myths that are promulgated by a client, who may be a person or a group of people or a department in an organisation that has requested for a software to be developed under contract.

1. Customers believe that a general statement of objective is all that he/she needs to communicate to the developers, the details can be filled later.

However, the truth is that a poor up-front is a major cause of failed software project. The fact is that formal description of the specification of the software in terms of information domain, functions, behaviour, performance, interface, design constraints etc is essential. This can be done through effective communication between the customer and the client.

• Customers believe that since software requirement changes continually, therefore, change can be accommodated because software is flexible.

However, the truth is that though software requirement can change, but the impact of the change depends on the stage the change is introduced. The cost implication of introducing change at the early stage of software project is low, while the cost implication of introducing change at the latter stage of software project is high.

• Practitioner;s Myths

These are software myths that are promulgated by software practitioners (i.e. analyst, designers and programmers).

1. Proctitioners believe that until they get the program running, there is no way that they can assess the quality of the software.

However, the truth is that formal technical review, which is one of the most effective formal software quality assurance mechanism can be applied from the time the software project started.

• Practitioners believe that once they write the program and get it to work, their job is done.

However, the truth is that the sooner you begin to write the code, the longer it will take to get the work done. This is because reliable statistics show that between 60% and 80% of software effors are expended after the software is delivered to the custmer at the first time.

• Practitioners believe that the only deliverable work product for a successful software project is the working program.

However, the truth is that the working program is only a part of the deliverable work product for a successful software project. Documentation, which provide a guide on what the program does and how to use the program is very important deliverable work product of a successful software project.

• Practitioners also believe that software engineering will make them to create voluminious and unnecessary documentation, which will slow down the whole process.

However, the truth is that software engineering is not about creating documents, but it is about creating quality. Better quality leads to reduced rework, and reduction in rework leads to faster delivery time.

• Though practioners agree that software is developed by a team, but most practitioners believe that software is developed by a team of software practitioners (experts), which includes system analysts, designers and programmers.

However, the truth is that software is developed by a team of expert and non-experts. The members of software development team should not be the experts only (i.e. analysts, designers and programmers), but it should include the representative of every group of people that has a stake in the system. It has been established that software developed by team members who are experts have many social problems, like rejection, abandonement and abseetism. These social problems can be prevented where a participatory approach to software development is in place. This approach allows people in the organisation to be members of the software development team, and make significant contribution towards the development of the software. The people believe that they are the architect of developed software, and will be willing to make it to succeed, instead of allowing few experts to impose technology on them.