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 3 of 5

What's more, the study Brooks cites was from 1966. Modern software project managers know better than to place too much faith in developer productivity metrics, which are seldom reliable. For one thing, code output doesn't tell the whole story. Brooks himself admits that even the best programmers spend only about 50 percent of the workweek actually coding and debugging.

This doesn't mean you shouldn't try to hire the best developers you can. But waiting for superhuman coders to come along is a lousy staffing strategy. Instead of obsessing over 10x developers, focus on building 10x teams. You'll have a much larger talent pool to choose from, which means you'll fill your vacancies and your project will ship much sooner.

 Programming myth No. 4: Cutting-edge tools produce better results
Software is a technology business, so it's tempting to believe technology can solve all of its problems. Wouldn't it be nice if a new programming language, framework, or development environment could slash costs, reduce time to market, and improve code quality, all at once? Don't hold your breath.

Plenty of companies have tried using unorthodox languages to outflank their competitors. Yammer, a social network, wrote its first version in Scala. Twitter began life as a Ruby on Rails application. Reddit and Yahoo Store were both built with Lisp.

Unfortunately, most such experiments are short-lived. Yammer switched to Java when Scala couldn't meet its needs. Twitter switched from Ruby to Scala before also settling on Java. Reddit rewrote its code in Python. Yahoo Store migrated to C++ and Perl.

This isn't to say your choice of tools is irrelevant. Particularly in server environments, where scalability is as important as raw performance, platforms matter. But it's telling that the aforementioned companies all switched from trendy languages to more mainstream ones.

Fred Brooks foresaw this decades ago. In his essay "No Silver Bullet," he writes, "There is no single development, in either technology or management technique, that promises even one order of magnitude improvement in productivity, in reliability, in simplicity."

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.


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

  • Print
  • Feedback

Resources