Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

7 programming myths -- busted!

Common misconceptions about productivity, code efficiency, offshoring, and more

By Neil McAllister, InfoWorld, 04/23/12

  • Print
  • Feedback
.

Page 4 of 5

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 percent) 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
A professional racing team's job is to get its car to the finish line before all the others. The machine itself is important, but it's the hard, painstaking work of the driver and the mechanics that makes all the difference. You might think that's true of computer code, too. Unfortunately, hand-optimization isn't always the best way to get the most performance out of your algorithms. In fact, today it seldom is.

One problem is that programmers' assumptions about how their own code actually works are often wrong. High-level languages shield programmers from the underlying hardware by design. As a result, coders may try to optimize in ways that are useless or even harmful.

Take the XOR swap algorithm, which uses bitwise operations to swap the values of two variables. Once, it was an efficient hack. But modern CPUs boost performance by executing multiple instructions in parallel, using pipelines. That doesn't work with XOR swap. If you tried to optimize your code using XOR swap today, it would actually run slower because newer CPUs favor other techniques.

Multicore CPUs complicate matters further. To take advantage of them, you need to write multithreaded code. Unfortunately, parallel processing is hard to do right. Optimizations that speed up one thread can inadvertently throttle the others. The more threads, the harder the program is to optimize. Even then, just because a routine can be optimized doesn't mean it should be. Most programs spend 90 percent of their running time in just 10 percent of their code.

In many cases, you're better off simply trusting your tools. Already in 1975, Fred Brooks observed that some compilers produced output that handwritten code couldn't beat. That's even truer today, so don't waste time on unneeded hand-optimizations. In your race to improve the efficiency of your code, remember that developer efficiency is often just as important.


For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.

  • Print
  • Feedback

Resources