12 programming mistakes to avoid

1 2 3 4 5 Page 5
Page 5 of 5

"A practical result of opening your code is that people you've never heard of will contribute improvements to your software," Gilmore says. "They'll find bugs (and attempt to fix them); they'll add features; they'll improve the documentation. Even when their improvement has been amateurishly done, a few minutes' reflection by you will often reveal a more harmonious way to accomplish a similar result."

The advantages run deeper. Often the code itself grows more modular and better structured as others recompile the program and move it to other platforms. Just opening up the code forces you to make the info more accessible, understandable, and thus better. As we make the small tweaks to share the code, they feed the results back into the code base.

Mistake No. 12: Assuming openness is a cure-all

Millions of open source projects have been launched, and only a tiny fraction ever attract more than a few people to help maintain, revise, or extend the code. In other words, W.P. Kinsella's "if you build it, they will come" doesn't always produces practical results.

While openness can make it possible for others to pitch in and, thus, improve your code, the mere fact that it's open won't do much unless there's another incentive for outside contributors to put in the work. Passions among open source proponents can blind some developers to the reality that openness alone doesn't prevent security holes, eliminate crashing, or make a pile of unfinished code inherently useful. People have other things to do, and an open pile of code must compete with hiking, family, bars, and paying jobs.

Opening up a project can also add new overhead for communications and documentation. A closed source project requires solid documentation for the users, but a good open source project comes with extensive documentation of the API and road maps for future development. This extra work pays off for large projects, but it can weigh down smaller ones.

Too often, code that works some of the time is thrown up on SourceForge in hopes that the magic elves will stop making shoes and rush to start up the compiler -- a decision that can derail a project's momentum before it truly gets started.

Opening up the project can also strip away financial support and encourage a kind of mob rule. Many open source companies try to keep some proprietary feature in their control; this gives them some leverage to get people to pay to support the core development team. The projects that rely more on volunteers than paid programmers often find that volunteers are unpredictable. While wide-open competitiveness and creativity can yield great results, some flee back to where structure, hierarchy, and authority support methodical development.

Related articles

This article, "12 programming mistakes to avoid," originally appeared at InfoWorld.com. Follow the latest news in programming at InfoWorld.com and with the Developer World newsletter.

Read more about developer world in InfoWorld's Developer World Channel.

This story, "12 programming mistakes to avoid" was originally published by InfoWorld.

Copyright © 2010 IDG Communications, Inc.

1 2 3 4 5 Page 5
Page 5 of 5
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon