|Developer Diary · You Heard It Here First · 21 December 2003|
|Bad Software is Better than No Software|
|From an occasional series on a wizard's secrets of creating software|
There is the perfectionist in all of us. We want to put our best foot forward and project a confident, reliable image of ourselves and our software to the rest of the world. This desire makes releasing defective software taboo for many developers. This tendency, however, denies usable products to millions. An important philosophical principle of software development is: bad software is better than no software.
I can think of many examples. For example, when Epson, a Japanese company, released their market-leading photo printer, the 2200, they originally included with it a complex software tool known as a grey scale balancer. This shipped with the European version of the product and most global versions. Managers at Epson USA, however, decided that this software was too complex, too difficult and would only result in frustration for the majority of users and so it was omitted from the US release. The result of this was thousands of professional photographers who are the core customers for this kind of product were (and still are) absolutely infuriated. They are denied the use of an important tool because some moron business person at Epson USA has decided to treat them like children who can't be trusted to use software that is too complex.
This pattern occurs throughout industry. Decision makers focus on a few bugs or assume because they can't figure their own product out in 5 minutes that it is unreleasable. "Make it easier to use and correct those bugs!" they say, "We can't release this as it is." Months and years drag on and users are the losers. Ninety-nine things work but the users are denied the use of the product because the 100th feature has a bug.
Corporate developers would be advised to look at how open source initiatives run their software. They constantly post their software, even development-only versions filled with bugs and mark tested versions as "stable". The user has the choice of using an older fairly stable version of the software with fewer features or trying out the latest, but possibly unstable version. This makes users very happy. They have full access to the software and can control what they use. They can make their own decision about what to try or not try.
To reiterate a point I made in an article last month release times should be based on a business cycle, not on the state of the software. When release time comes, ship it! Remember: bad software is better than no software.
|return to John Chamberlain's home · diary index|
|Developer Diary · email@example.com · bio · Revised 21 December 2003 · Pure Content|