Software Management Myths, Customer Myths & Practitioner Myths.
Myth is defined as "widely held but false notation" by the oxford dictionary. We can also say that myth is an unproved or false collective belief. As in other fields software arena also has some myths to demystify.
Pressman describes a number of common beliefs or myths that software managers, customers, and developers believe falsely. He describes these myths as "misleading attitudes that have caused serious problems."
Primarily, there are three types of software myths, all the three are stated below:
Management Myth
Customer Myth
Practitioner/Developer Myth
Management Myth
Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a drowning person who grasps at a straw, a software manager often grasps at belief in a software myth, if those beliefs will lessen the pressure (even temporarily). Some common managerial myths stated by Roger Pressman include:
- Development problems can be solved by developing and documenting standards.
Standards have been developed by companies and standards organizations. They can be very useful. However, they are frequently ignored by developers because they are irrelevant and incomplete, and sometimes incomprehensible.
- Development problems can be solved by using state-of-the art tools.
Tools may help, but there is no magic. Problem solving requires more than tools, it requires great understanding. As Fred Brooks (1987) says, there is no silver bullet to slay the software development werewolf.
- When schedules slip, just add more people
This solution seems intuitive: if there is too much work for the current team, just enlarge it. Unfortunately, increasing team size increases communication overhead. New workers must learn project details taking up the time of those who are already immersed in the project. Also, a larger team has many more communication links, which slows progress. Fred Brooks (1975) gives us one of the most famous software engineering maxims, which isa mythnot a myth, "adding people to a late project makes it later."
Customer Myth
A customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing/sales department, or an outside company that has requested software under contract. In many cases, the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths lead to false expectations (by the customer) and, ultimately, dissatisfaction with the developer. Commonly held myths by the clients are:
- Change is easily accommodated, since software is malleable.
Software can certainly be changed, but often changes after release can require an enormous amount of labor.
- A general statement of need is sufficient to start coding
This scenario is an exaggeration. However, for developers to have a chance to satisfy the customers requirements, they need detailed descriptions of these requirements. Developers cannot read the minds of customers.
