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.
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.
- 7 programming languages on the rise
- Programming IQ test: Round 1
- Programming IQ test: Round 2
- Agile programming 10 years on: Did it deliver?
- InfoWorld review: Eight PHP power tools
- InfoWorld review: Nine fine Python development tools
- Lab test: Climb aboard Ruby on Rails
- InfoWorld review: Top Java programming tools