The Subjectivity of Software
In his blog, author Jonah Lehrer relates the story of several experiments run around wine tasting. One experiment involved coloring a white wine red, the other involved putting the same wine in two different bottles. In both experiments, expectations overrode the reality of the wines. So the same wine in the more expensive bottle tasted better and the white wine that was colored red tasted like a red wine.
In his post, The Subjectivity of Wine, Lehrer presents the argument that the exterior factors, the context of an object and our expectations towards it, have just as much influence on our perception of that object as its inherent qualities:
As the philosopher Donald Davidson argued, it is ultimately impossible to distinguish between a subjective contribution to knowledge that comes from our selves (what he calls our "scheme") and an objective contribution that comes from the outside world ("the content").
Lehrer's post may make you feel better if you ever felt snubbed at a wine tasting by a know it all, but it also has important implications for software development. The context of a piece of software can matter just as much as its content. Meaning that there is an explanation behind the common complaint you hear from developers than that an "inferior" product is displacing their preferred and technically superior one.
Defining the context of a piece of software is tricky. The user interface is so inherent to software that it isn't really fair to call it the context. A more valid definition of the context of software would focus on the soft factors around it. Is the producer of the software seen as a reputable and reliable vendor? Was the software coded by senior developers or junior interns? Is it free or does it cost money? Is it a much anticipated upgrade or a forced one?
A lot of these questions are good ones to ask. Since most of us don't have the time or access to evaluate the software we use at the code level, it is a useful mental short-cut to feel more comfortable about a product coming from someone you trust (since they have a proven track record) or a product you paid a lot for (surely they would not be able to get away with charging a lot for something that wasn't good). Like all short-cuts though this approach is not full proof. There are innumerable examples of the free products that are superior to their commercial ones. Not everything from Apple will help harness your creativity, etc.
Of course a product that fails utterly at its purpose will not be able to disguise its flaws from its users. However, it is worthwhile to note that part of the experience of using a piece of software is how you feel about it; how you feel about the software depends not only on functionality, but on the context of it. So, if you have spent the time it takes to make a quality technical solution, take some extra time to think about how you can put that solution into the most favorable context. Having the best code isn't always enough.