12 programming mistakes to avoid

The dirty dozen of application development pitfalls -- and how to avoid these all-too-common programming blunders

Current Job Listings
1 2 Page 5

The irony is that, despite being obsessed with feature check lists when making purchasing decisions, most users can't handle the breadth of features offered by any given piece of software. Too often, extra features clutter the experience, rendering the software difficult to navigate and use.

Programming mistake No. 10: Overdetermining the user experience
Some developers decide to avoid the trouble of too many features by offering exactly one solution. Gmail is famous for offering only a few options that the developers love. You don't have folders, but you can tag or label mail with words, a feature that developers argue is even more powerful.

This may be true, but if users don't like the idea, they will look for ways to work around these limitations -- an outcome that could translate into security vulnerabilities or the rise of unwanted competition. Searching for this happy medium between simple and feature-rich is an endless challenge that can prove costly.

Programming mistake No. 11: Closing the source
One of the trickiest challenges for any company is determining how much to share with the people who use the software.

John Gilmore, co-founder of one of the earliest open source software companies, Cygnus Solutions, says the decision to not distribute code works against the integrity of that code, being one of the easiest ways to discourage innovation and, more important, uncover and fix bugs.

"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 amateurly 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.

Programming 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.

1 2 Page 5