Software Myths mean beliefs about software and the process used to build it - can be traced to the earliest days of computing. Myths have a number of attributes that have made them insidious. For instance, myths appear to be reasonable statements of fact, they have an intuitive feel, and they are often promulgated by experienced practitioners who "know the score".
However, within this exists some myth which implants wrong idea to us. These myth exists among management, customer as well as practitioner.
Now lets we go through deeply.
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. Sometimes this pressure leads managers towards software myth as it lessen the pressure.
An example of management myth is as stated below:
IF WE GET BEHIND SCHEDULE, WE CAN ADD MORE
PROGRAMMERS AND CATCH UP
Many do not realize that the reality behind this myth is that software development is mechanistic process like manufacturing. It is true that when more people is added, a job gets done quicker. However, when new people are added, the one's existing has to spend time educating newcomers and this causes amount of time spent on productive development to be reduced. People can be added only in a planned and well coordinated manner.
CUSTOMER MYTH
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. Most of the time, customers believes that software managers and practitioners do little to correct misinformation. Thus it leads to false expectations and dissatisfaction with the developer.
An example of customer myth is as stated below:
SOFTWARE REQUIREMENTS CONTINUALLY CHANGE,
BUT CHANGE CAN BE EASILY ACCOMMODATED BECAUSE SOFTWARE IS FLEXIBLE.
According to the myth, the reality of it is actually software requirements change, but the impact of change varies with the time at which it is introduced. When requirements changes are requested early, the cost impact is relatively small. However as time passes, the cost impact grows rapidly as the recourse have been committed, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification.
PRACTITIONER MYTH
Practitioner refers to the person who practices something which could be a profession, an occupation or technique which in this case refers to software development or engineering. Did you know, that long time ago programming was viewed as an art form? Well old ways and attitudes die hard.
An example of practitioner myth is as stated below:
UNTIL I GET THE PROGRAM "RUNNING" I HAVE NO WAY OF ASSESSING ITS QUALITY.
The reality of this myth actually is that we should know that the most effective software quality assurance mechanisms can be applied from the inception of a project such as technical review. Software reviews are a "quality filer" that have been found to be more effective than testing for finding certain classes of software defects.
Message From us:
We hope you can understand what is software myth. Actually there are a lot of software myth that you can find but for us what have been describe above is mostly what we love.
Created by: Santhi A/P Parambalam and Siti Assyifa
