For example, when the U.S. Department of Defense developed the Ada language in the 1970s, its goal was to revolutionize programming -- no such luck. "[Ada] is, after all, just another high-level language," Brooks wrote in 1986. Today it's a niche tool at best.
Of course, this won't stop anyone from inventing new programming languages, and that's fine. Just don't fool yourself. When building quality software is your goal, agility, flexibility, ingenuity, and skill trump technology every time. But choosing mature tools doesn't hurt.
Programming myth No. 5: The more eyes on the code, the fewer bugs
Open source developers have a maxim: "Given enough eyeballs, all bugs are shallow." It's sometimes called Linus' Law, but it was really coined by Eric S. Raymond, one of the founding thinkers of the open source movement.
"Eyeballs" refers to developers looking at source code. "Shallow" means the bugs are easy to spot and fix. The idea is that open source has a natural advantage over proprietary software because anyone can review the code, find defects, and correct them if need be.
Unfortunately, that's wishful thinking. Just because bugs can be found doesn't mean they will be. Most open source projects today have far more users than contributors. Many users aren't reviewing the source code at all, which means the number of eyeballs for most projects is exaggerated.
More importantly, finding bugs isn't the same as fixing them. Anyone can find bugs; fixing them is another matter. Even if we assume that every pair of eyeballs that spots a bug is capable of fixing it, we end up with yet another variation on Brooks' Mythical Man-Month problem.
One 2009 study found that code files that had been patched by many separate developers contained more bugs than those patched by small, concentrated teams. By studying these "unfocused contributions," the researchers inferred an opposing principle to Linus' Law: "Too many cooks spoil the broth."
Brooks was well aware of this phenomenon. "The fundamental problem with program maintenance," he wrote, "is that fixing a defect has a substantial (20 to 50%) chance of introducing another." Running regression tests to spot these new defects can become a significant constraint on the entire development process -- and the more unfocused fixes, the worse it gets. It's enough to make you bug-eyed.
Programming myth No. 6: Great programmers write the fastest code