Here’s an interesting phrase:
superficial convenience at the expense of real freedom
This comes from the conclusion of the 1998 essay The Elements of Style: UNIX as Literature by Thomas Scoville. The author sums up his preference for UNIX culture by saying he prefers the “freedom and responsibility that UNIX allows” to the “superficial convenience” of Windows NT.
I’m not interested in arguing here the relative merits of Unix and Windows. I’m more interested in broader ideas that spin off from the quote above. When is a convenience superficial? How well does convenience versus freedom explain technological controversies?
I could see substituting “short-term convenience” for “superficial convenience” and substituting “long-term efficiency” for “real freedom.” But that may lose something. Thomas Scoville’s terms may be more nuanced than my substitutions.
12 thoughts on “Superficial convenience”
This reminds me of the convenience vs. privacy debate regarding tools like Gmail, Facebook, etc., that collect large amounts of your data and use it to make some things easier for you (friend suggestions, the priority inbox, etc). My stand on this is: if it makes my life significantly easier, I’m for the convenience. I think it ultimately ends up being a matter of subjective balance, on which each person has to decide by themselves.
Data portability and application lock-in, leading to application domination and stagnation of competitors seems to be an example of the original quote. If your data can be easily opened / analysed by another application than the one which created it, application makers have to compete on functionality and long-term usefulness. You are free to move to another app, or write your own tools to work with the data and, hence, not locked in. That’s long-term freedom (but not necessarily long-term efficiency). Compare with something like MS Word format, or ActiveX components that don’t run on IE versions later than 6 — the initial convenience of the format forces large groups into forced, and consequently costly, due to lack of true available-now competition, upgrade paths.
How about changing the comparative scale to one of limited freedom and responsibility at one extreme, versus unlimited freedom and responsibility at the other? There are of course varying degrees in the middle.
I’d say it’s important to stress the /type/ of freedom and responsibility implied here: namely /technical/ freedom and responsibility.
Sometimes I want the freedom to be superficial. I just want something to work right now with minimum hassle.
I think a lot of what you’re talking about is laid out by Neal Stephenson in “In The Beginning… was the Command Line, particularly his stuff about Morlocks and Eloi.
‘Superficial Convenience’ is an Eloi thing, ‘Real Freedom’ is a Morlock thing, and even Stephenson says that nobody, or almost nobody, is one or the other all the time.
Chris: Good point. And I really like Neal Stephenson’s essay.
Malcolm: Excellent example of “freedom” really meaning freedom rather than efficiency.
I used to dismiss people who feared vendor lock-in. Now I see how insidious it can be. Lock-in may be an acceptable trade-off, but it’s subtle.
Data portability’s been really hard. Back when I routinely used Unix, programs were portable across flavors of Unix and compilers, but you had tons of #ifdefs all over the place, and custom makefiles galore. HTML/CSS is “portable” but there are tons of shims for browser quirks (mostly ie6, which needs to die).
I’d say that I’m mostly a Windows person, but it’s interesting to see how the world has gone. The iPhone/iPad share a codebase with OS X. Android phones run Linux. Windows phones don’t share a code base with regular Windows. (Older phones run Windows CE, I have no idea what the current phones use.)
I see this “Convenience vs. Control” issue in many products, not just with Windows and Unix. I recently had a car with “computer assisted” windshield wipers, the idea being that on the intermittant setting the car would detect when to cause the wipers to wipe. The problem was I wanted the wipers to wipe at different times than the computer determined wipes were needed, and all the dial adjusting in the world couldn’t align the two. Sometimes it’s nice to let the computer handle it; sometimes you just want the control to do it your own way.
“Superficial convenience” seems a somewhat loaded term. As you mention above John, lock-in may be even an acceptable—though subtle—trade-off. Superficiality implies that one is unaware of the trade-off involved in acquiring the convenience.
Perhaps it is more correct to talk of “interactive” freedom (IF) (i.e., time saving, easy, intuitive etc.) as opposed to “superficial convenience”. Often IF is acquired at the cost of “technical freedom” (TF) and “technical responsibility” (TR) (e.g., Windows NT). This is not always the case however, as there exists software with relatively high levels of IF, as well as very high levels of TF (e.g., Ubuntu) or very high IF with relatively high TF (e.g., MacOS). Fortunately there are many different permutations to suite many different needs.
I guess that none of that matters if one is unaware of the cost of convenience (or freedom for that matter). Therefore the superficiality is in the ignorance, the freedom in the knowledge.
I think the better analogy would be “junk food usability”. Something that seems delicious and awesome but is really just cheap sugar, fat, and/or salt. A bigmac or a twinkie versus sushi or a steak, for example. Junk food is easier to appreciate and cheaper to acquire, but fine cuisine is far more delicious.
“This is not always the case however, as there exists software with relatively high levels of IF, as well as very high levels of TF (e.g., Ubuntu) ”
What? whenever I talk to people who use Linux on the desktop, I end up being told that “X worked fine but then I upgraded my Suse/Ubuntu/whatever and it stopped working”, with X = sound, wifi, Citrix client, whatever. That’s mighty low IF and just an illusion of TF.
In order to merit the term “superficial convenience” the product/feature should appear desirable yet provide a net negative effect rather than either being a technical tradeoff, or simply non-functional.
For example: inexpensive metal lathes typically arrive assembled (or very nearly assembled). This seems convenient as it’s a trivial matter to start using the lathe as soon as you’ve unboxed it. However, in order to produce a useful product the lathe must be broken down to component parts for cleaning and maintenance prior to re-assembly. Ultimately, it would be more convenient if the lathe had been shipped completely disassembled.
I’ve worked with a number of library APIs that fell into this category where it would’ve been simpler to just re-implement the feature internally.
Also: I used to fear vendor lock in. That was before I learned to fear companies who should never be allowed to handle their own data.