Myths have accompanied man since ancient times and still exist in our high-tech world. So despite the fact software development is a fairly formal science, this does not prevent the existence of many myths and misconceptions in this industry. In this article, we will discuss just some of them.

Myth#1. One programming language is better than others
Programmers love to praise the language in which they program. You can often hear that some language is better than others. But the truth is that each language serves a specific purpose, and one cannot say for sure that one language is better than another. It’s like asking which language is better: Italian or French? Surely, it depends on the country in which you are located. On this basis, the benefit of a specific programming language can only be determined within a specific task. And often tasks require knowledge of several languages. Therefore, languages ​​work together, not against each other.

Myth#2. More people are better
So if we fail in the planning, we can add more programmers to the team and advance the lost time. This situation sometimes called as “concept of the Mongolian horde”. In fact, software development is not a mechanical process like manufacturing. So usually adding people to a delayed software project delays it even more. At first, this statement may seem counterintuitive. However, when new people are added, it is needed to learn them and to spend time communicating with the team. So this amount of time cannot be spent on product development. People can be added, but only in a planned and well-coordinated manner.

Myth#3. Programmers can only write code.
The creators of such myths about programming are undoubtedly very far from this sphere and do not know how the development process takes place. Usually, the problems solved by computer programs go far beyond the field of information technology. For example, let’s take the tools for accounting. In order to create a quality product, the programmer should, in general, understand this subject area.
The ideal is the option of cooperation of a professional accountant who knows what he wants and a coder who understands programming and knows how to explain to a machine what to do. However, an accountant in most cases is too far from computer science and is simply unable to explain in detail what he expects from the product. So, the programmer has to go into economic concepts and schemes on his own.

Myth#4. Faster is better
Yes, there are projects that can be easily and quickly implemented through the designer and a set of custom solutions from the company’s experience. But these projects, as a rule, close a very narrow target audience and will not bring a high income to the owners of this product. All serious engineering solutions are often not only developed over several years but also require support and have been developed over the years. For example, the history of the creation of the Microsoft Office package. When the task was assigned to it, the implementation period was estimated at 3 months. As a result, the project itself took 6 years.
As a result of this myth, there is an opinion that programmers work around the clock. However, trawls, processing and other — they do not bring anything good. Developer productivity drops dramatically if they are forced to work long hours. And it falls so much that in ten hours they begin to do as much as they used to do in six. Therefore, many companies are convinced that programmers cannot work more than six hours a day. After all, both the speed and quality of work are sharply reduced further, which is much worse.

Myth#5. Sticking to the plan is a must
It is indisputable, that software development is a set of complex actions that require coordination and attention to detail. So planning is surely is a must. In the early stages of development, it is very important to dive deep into the details, think over the functionality in detail and carefully study the technical task. But not always everything goes according to plan. It is really hard to meet a project, the requirements for which have remained constant throughout the development. For manufacturing processes with frequent repetition of steps, this is a good approach to track every step — but it is not suitable for innovation in development. New insights can come daily, and conditions can change constantly. So plans should be considered as initial hypotheses that are constantly being revised.

Myth#6. Nothing is impossible
The widespread myth “nothing is impossible” became one of the foundations for this myth. The fact is that, at the mention of IT, there are rarely any limitations and “inconvenient” conditions. For example, if you look at the interface of any search engine from the perspective of an ordinary person, you will not see any difficulties. A set of small phrases and small pictures. However, this is all worth much more than it might seem. Everything has its limitations, even IT sphere.

Myth#7. Success from the first trial
Experiments with different ideas are an indispensable part of the innovation process. When you experiment often and quickly, of course, you will have to accept the failure of many ideas. But it allows teams to quickly cast away bad decisions and concentrate on more promising ones.
Success from the first time sends teams to the territory of less risky decisions — even if customers do not consider them to be a significant improvement over what they were before. Teams do not receive an incentive to develop innovative solutions to user problems.

The above are only the most popular myths, but besides them, there are many others. All of them in some way create a culture of IT-sphere. Developers, like all other professionals, have their own traditions and customs, sometimes even very funny, but this is another story.