The Perl Journal February, 2005
I heard a report on the radio the other day about studies that show that American consumers are becoming increasingly indifferent to traditional notions of product quality. It used to be (50 years ago, at any rate) that salespeople put the quality of a product's construction at the top of a sales pitch. If you could convince Mr. and Mrs. America that their blender was going to last 50 years, you had them.
Not so these days. Quality no longer means durability and solid construction. It has come to mean "packed with features." We're so much more affluent now that, with a few exceptions, we actually expect to discard most things we buy within a few short years. So we want to be sure our new digital camera has more bells and whistles than the last camera we bought (and maybe more bells and whistles than the one our neighbor has), but we're really not all that concerned about whether it will still be functioning in 10 years. Salespeople just can't get anywhere selling digital cameras that are "built to last."
One of the major engines behind this change in consumer attitudes is the rapid pace of innovation in digital electronics. We expect a product to be obsolete even before its components wear out, so longevity doesn't matter. And if cheaply built products are more affordable, so much the better. This new definition of quality—a high features-to-price ratio instead of durability—has spread to other industries, helped along by commoditization and the price pressures brought about by cheap offshore labor.
Software is probably connected to this trend, but it's hard to say for sure because software is so fundamentally different from other products. What does "quality" mean in software? It has never meant "durability," since binary code doesn't wear out. If your operating environment never changes, your code will continue to operate in exactly the same way for all eternity. Of course, no one's operating environment stays the same. We constantly upgrade our OSes and install other software that alters the computing environment. So old software does break, but only indirectly. This enforced obsolescence has led us to see software as being just as ephemeral and fragile as the cheap physical goods that we buy. Software has been dragged along with the PC in a downward spiral—we throw away our obsolete PC after three years of use, and often our perfectly functioning software must go with it.
It's impossible to make software that's "built to last." You can't know what changes in environment will break your code in the future. The best you can do is make it function perfectly now. Make it do as much as possible for the user, without error and without confusion. And make your code as easy to alter as possible, so that when new code inevitably must be written, the path is clear.
Kevin Carlson
Executive Editor
The Perl Journal