Software delivers the most important product of our time, information. It transforms the most seamlessly unreadable data into a more useful context. It transforms personal data, manages business information to enhance productivity, customer experience, and competitiveness. It makes the local library seem archaic while the world’s largest library is accessible from the click of a button, via the internet, it provides the means for gaining all forms of information.

Over the last 5 decades, the role of software has undergone significant changes. Sophistication and complexity can produce mind-blowing results when a software succeeds, but for those who must build complex systems, this also poses huge problems.

Gone or limited, the days where we have the lone programmer cranking it out. At least back then when things didn’t work you could blame this lone programmer. However, this loneliness has been replaced by teams of software specialists. Where each specialist focuses on one part of the technology that is required to deliver an application. However, the same questions being asked of the lone programmer are also being asked when modern software systems are built.

Why does it take so long to get the software finished?

Why are development costs so high?

Why can’t we find all the errors before we give the software to customers?

Why do we continue to have difficulty in measuring progress as software is being developed?

Do you still have these questions? These are a manifestation of the concerns about software and the manner in which it is developed. These concerns have lead to the adoption of software engineering practice.

There was a time where less than 1% of the pubic knew how to properly define what “computer software” meant. Today, while it may not be such a small percentage, professionals and many others feel that they understand software. But do they? Many causes of software disappointments can be traced to a mythology that arose during the early history of software development. Unlike ancient myths that provided human lessons well worth listening to, these myths cause misinformation and confusion. Software myths had a number of characteristics that made things worst; They posed somewhat reasonable statements as facts.

Today, most knowledgeable professionals recognize myths for what they are, misleading. However, old attitudes and habits are difficult to modify, and remnants of software myths are still believed. Let’s take a look at some of these myths that you may have as a problem disguised as a tool.

Customer myths

In many cases, the customer believes myths about software because software managers and developers do little to correct them. This leads to false expectations and ultimately, dissatisfaction with the developers.

Myth: General statement of objectives/requirements is sufficient to begin writing software.

Reality: The lack of a detailed up-front definition of what the software should do is a major cause of software failures. A formal and detailed description of the information domain and success criteria is absolutely and irrevocably essential.

Myth: Although project requirements continually change these changes can be easily implemented because software is “flexible”.

Reality: Software requirements do indeed change, however, the impact of these changes increases drastically as time goes by. The later the change was introduced the more expensive the change becomes. If the right amount of effort was put into generating a detailed analysis and design of the system to be built, the customer (you), can review the requirements and recommend the modification you see fit with a low impact on cost. When resources have been committed and design has been established. Change can cause upheaval that requires additional resources and major design modifications.

Management myths

Managers in the software fields are like any other manager in any other field, under constant pressure to maintain budgets, keeping the timelines from sliding, improve the quality of the organization output. However, software managers often reach for certain software myths to provide guidance to his/her dismay to relieve the pressures of the job.

Myth: My guys have powerful development tools and the latest computers.

Reality: Sadly, if it were up to the tools everyone would be a rockstar. It takes much more than the latest workstation, tools, or PC to do high-quality software development. Don’t get me wrong high-quality tools are essential to produce quality software and drive productivity. Yet ask yourself how many of your guys are using them effectively? Why is that the software being produced still has the same issues as before the upgrade in tools and computers?

Myth: Our people have a book that’s full of standards, best practices and procedures for building software, won’t that provide them with everything they need to know?

Reality: Well these standards might exist but are they being utilized? How do you know they were used? Can it be easily integrated in a manner that improves time to market?

Myth: If we get behind schedule, we can add more programmers and catch up.

Reality: Adding more people to a late software project makes it even later. The people who were working will now have to spend time educating the new guys and reducing the time spent on product development. People can be added but only in a planned manner.

Myth: If I outsource the software project to a third party, I can just sit back and let that firm build it.

Reality: If you don’t understand how to manage and control software projects in house, you will definitely struggle when it comes to outsourcing software projects. If you don’t know what good quality software development looks like how are you able to judge the quality and the work done by others?

Developer myths

Myths that are still believed by software developers have been fostered by years of programming culture. During the early days of software, programming was viewed as an art form. Development is not a hollywood scene where there is a guy in a dark room cranking 100s of lines of code out of thin air at flash-like speeds, presses the enter button, and everything just works flawlessly.

Myth: Once we write the program and get it to work, our job is done.

Reality: Someone once said that “the sooner you begin ‘writing code’, the longer it’ll take you to get done”. Another goes like this, a plan of action lasts only as long as the first contact with the user. Meaning the original work done on software is just the beginning. Only until after the first user lays eyes on it you’re soon to find out 80% of your assumptions are off and your efforts will expand after it is delivered to the customer for the first time.

Myth: I have no way of assessing its quality until after it is finished.

Reality: Software quality assurance mechanisms can be applied from the inception of a project. It doesn’t need to be until the end.

Myth: The main and only deliverable for a successful project is the working program.

Reality: A working program is far from the only thing that needs to be done. A working program is only a small portion of the overall objective of the software in the first place. When is a computer software successful? Is it when you click a button and does something without breaking or is it when it meets the needs of the people who use it, or that it performs flawlessly over a long period of time. A working program is only one part of a software building that includes many elements.

Myth: Documentation will invariably slow us down.

Reality: Documentation is not just about creating documents. It is about creating quality. Better quality leads to reduced rework, reduced rework results in faster delivery times.