7 myths about programming

As you know, our Jelastic project was created to make life easier for developers, and, of course, we always listen to their wishes, study their psychology, thinking and other aspects. Below we publish an article by one of the leading computer publishers, Neil McAlister , which was previously published in InfoWorld and our English blog .
Some of the provisions of the article may seem controversial (for example, we are in a sense, themselves “offshore” with our development in Russia and Ukraine), but they are all extremely interesting.

It turns out that even such rational people with advanced logic, as developers, believe in myths. Some programmers believe in what they want to believe, against all odds.
For example, the classic misconception is the view that it is possible to speed up the development of a project by adding more developers. Frederick Brooke dispelled this myth back in 1975 in his book The Mythical Man-Month.
Brooke believed that adding developers to an already well-developed project would not speed up the process. On the contrary, it will slow down the development process even more. In fact, it refutes many generally accepted concepts regarding the management of software projects.
Of course, some examples of Brooks seem to be outdated today, but the general idea is still relevant. His arguments are very convincing. 37 years later, mythical thinking continues to prevail among programmers. We continue to make the same mistakes.
Here are a few examples of modern programming myths, many of which originate from more ancient delusions.

Myth number 1: Offshore software development

Nowadays, no sane person would think about launching a large software project without an “offshore” strategy. All major software vendors do this, moreover, Silicon Valley investors insist on this approach. It all sounds quite logical: you can use more developers for less money. So you can finish the project early, and save.
But wait! This is a classic example of a misconception from the Mythical Person-Month. We already know that involving more people, and even remotely, will only make things worse.
According to Brooks: "Adding people to software development increases the overall effort in three ways: disintegration, training new people, and additional communication."
Suppose that the effort required to train new remote personnel is the same as for home-grown developers (dangerous assumptions). There are more problems with outsourcing communication. Language, culture and time zones only add overhead. Moreover, remote development teams are often prone to high staff turnover, so communication rarely improves over time.
Outsourcing is not magic. In fact, it is difficult to draw any definite conclusions about this. This free lunch can end up costing more than you expected.
')

Myth number 2: Good developers work for days

Everyone knows the stereotype: programmers "code" and day and night long, pizza and energy drinks - their best friends, they work on weekends and are rarely at home.
Of course, there is a lot of truth in this. According to medical research, programmers are in fifth place among the “sleep-deprived” professions. Long working hours are not uncommon, especially in the gaming industry.
But it should not be so. There is ample evidence that this approach does not increase productivity. In fact, it hurts more than benefits.
Most often, software projects are late with launch due to incorrect deadlines, unclearly defined steps or additional tasks that have arisen during the development process. As short delays are added, programmers are forced to work in extra mode, but their efforts are spent on achieving goals that can no longer be achieved. The launch of the project is postponed even more and the morale of the team is lost.
Some developers are satisfied with the work "until you drop", but most have families, friends and personal life, like all people. They would be happy to leave the office at 18.00. So, instead of encouraging coders to work overtime, it’s better to focus on why they should linger and how to fix it. They will appreciate it much more than free pizza at one in the morning.

Myth number 3: Cool developers are 10 times more productive than others

Good developers are very hard to find, but great coders are legends, or at least local legends.
If you believe in fairy tales, then they say that somewhere there are so experienced hackers who are an order of magnitude more productive than the average programmer.
Naturally, recruiters and hiring managers will kill to find these legendary "demigods code." However, for the most part, they remain as elusive as a snowman. Probably they simply do not exist.
Most developers are somewhere in the middle. If you see a superproductive coder in your team, then most likely the other developers are very weak.
Moreover, Brooke's research proves that the output code does not provide a complete assessment of performance. Even the best of the best spend only about 50% of the work week on coding and debugging.
Waiting for a superdeveloper is a bad strategy. It is better to create a supercommand from medium coders that will complement each other. So you will have much more talents.

Myth number 4: Modern tools provide better results.

Software is a technology business, and one wants to believe that technology can solve all problems. It would be nice if a new programming language, framework, or development environment reduced costs, reduced time to market, and also improved the quality of the code.
Many companies have tried to use non-traditional languages ​​to circumvent their competitors. The first version of the Yammer social network is written in Scala. Twitter began life as a Ruby on Rails application. Reddit and Yahoo Store were both built using Lisp.
Unfortunately, most of these experiments are short-lived. Yammer switched to Java when Scala failed to ensure normal operation. Twitter switched from Ruby to Scala, and then partially to Java. Reddit rewrote their Phyton code. Yahoo Store migrated to C ++ and Perl.
This does not mean that the choice of tools does not matter. In particular, in server environments where scalability is as important as performance. But, as we see, many companies have moved from more fashionable solutions to traditional ones.
For example, when Ada was developed in the USA in 1970, the main goal was the so-called programming revolution - but alas. Today it is a niche tool at best.
Of course, this will not stop anyone from the inventors of new programming languages, and this is normal. Just do not be fooled. When your goal is to create high-quality software, dexterity, flexibility, ingenuity and skill overcome technology in two ways. For this, the choice of a mature tool does not hurt.

Myth number 5: The more eyes check the code, the fewer bugs

Open source developers have an aphorism: “With a sufficient number of eyes, all errors lie on the surface.” This is sometimes called the Linus law, but it was really Eric S. Raymond, one of the founders of the open source movement.
The idea is that open source has a natural advantage over proprietary software, because any developer can view the code, find flaws, and fix them if necessary.
Alas, this is wishful thinking. Most open source projects today have far more users than participants. Many users do not even view the source code, which means that the number of eyes is exaggerated for most projects. Moreover, the finding of errors does not mean their elimination.
One of the studies conducted in 2009 showed that the code files that were corrected by many individual developers contained much more bugs than the ones that the programming teams worked on. As it is known: “at seven nannies there is a child without an eye”.

Myth number 6: Cool developers optimize code to the maximum

The job of a professional racing team is to get their car to the finish line before the rest. The machine itself is very important, but this is only iron, which requires the hard work of the driver and mechanic. Do you think this is true for computer code too? Unfortunately, manual optimization is not always the best way to get the maximum performance from your algorithm. In fact, today it is very rare.
One of the problems is that programmers' assumptions about how their own code actually works are often erroneous. High-level languages ​​protect the programmer from the hardware. As a result, coders may try to optimize the code in such a way that it is often useless and often even harms the project.
Take, for example, the XOR paging algorithm, which uses bit operations to change the values ​​of two variables. Once it was effective. But modern high-performance processors increase performance by simultaneously executing several instructions using pipelines. If you are trying to optimize your code in this way today, it really works slower.
Multi-core processors also complicate matters. To use them, you need to write a multi-threaded code. Parallel processing is difficult to do correctly. Optimization that speeds up one thread may accidentally interrupt the others. The more threads, the harder the program to optimize. The fact that the procedure can be optimized does not mean that it necessarily has to be done. Most programs spend 90% of their launch time on processing just 10% of the code.
In many cases, you better just trust your tools. Do not waste time on unnecessary manual optimization, better take care of the efficiency of the code.

Myth number 7: A good code is an “elegant” code.

Like most engineers, programmers like to talk about simple or "elegant" problem solving. The trouble is that this is a bad way to judge software code.
What do these terms really mean? Is there a simple or “elegant” solution? Does this “elegant” code work efficiently, or is it the code that uses the least number of lines?
In a sense, the search for the most "elegant" solution to the problem of programming is another type of premature optimization.
Good code may not be so simple or "elegant." The best code works, works well, and without bugs. Why ask for more?