The World

[as I find it]

Software is Not Just a Tool

One of the most frustrating things I do in my daily work is wrangle with CSS. Trying to get a particular website to display correctly on multiple browsers and screen resolutions without ruining my HTML semantics can be an extremely painful process. Anyone who’s ever had to do this knows the reason: browsers implement CSS differently, and sometimes (in the case of Internet Explorer) incorrectly and without any sort of sanity. The causes behind these different implementations are various, but they include varying interpretations of the standard, disregard for the standard, and the fact that users cannot submit patches to improve CSS support in proprietary browsers.

Groaning about CSS bugs in Internet Explorer is a favorite topic on forums across the Web, but most people seem resigned to their existence and (begrudgingly) implement their own hacks and fixes, including reverting to table-based layouts. I have never seen or heard a cogent discussion of the reasons why Internet Explorer is the way that it is, or what can be done about it.

This problem is not unique to web browsers and web design. It is an inherent tension present whenever proprietary software is used to read and write data that’s supposed to adhere to an open standard. Open standards tends to evolve; proprietary software does not tend to evolve to meet them. This is partly due, I assume, to a resource allocation problem: it’s possible that even huge proprietary software companies like Microsoft can lack the resources (or willpower) to stay abreast of changes in standards over which they have little control. A bigger contributor is psychology: a culture of software ownership does not tend to foster the values of deferring to standards for the good of a group, sharing code and patches, or contributing in any other way to a community which does not recognize software property “rights.”

Ignoring standards is evil?

Contrary to popular belief, I tend not to think that Microsoft and other proprietary software outfits ignore or imperfectly implement data standards because they’re “just evil” or anything of the sort. Believing that might bring you some emotional comfort, but it’s an uncritical and shallow explanation that does little to remedy the problem. Instead, I think this behavior is rooted in a variety of cultural attitudes historical events, and conventional wisdom and platitudes. In the rest of this post, I want to focus on one such bit of conventional wisdom, which I think is a major contributor to the way that both proprietary software companies view open data standards, and users’ acceptance of those views: the belief that software is “just a tool.”

This is a belief that Microsoft in particular has promoted for some time. Microsoft makes most of its money from fairly boring, functional products: Windows and Office. The software in these products is basically designed to facilitate users’ accomplishing a series of well-defined tasks: writing a document, calculating a budget, sending an email, starting up and shutting down. Microsoft has a concerted interest in making sure that their users don’t think of software as anything other than a means to these pre-defined ends, because if users did think that, they might start to want things like well-designed graphical interfaces, open APIs and data formats that would allow them to extend the software for other purposes, and a general hackability that would make defining and accomplishing one’s own tasks easier.

Tools

There’s no doubt that computer programs — at least some computer programs — are tools for accomplishing tasks. On the most basic level, programs are a series of instructions that turn inputs into outputs. Inputs come from users, and outputs are meaningful to users. We design and run programs with the express intention of getting from one end of this chain to the other, but what happens in between may or may not matter to us. When you think of software as just a tool, you’re taking the latter perspective: you don’t care how it does the job, as long as the job gets done.

The problem is that, in reality, we all care at least a little bit about how a program does its job. Programs don’t generally run in an isolated environment, and can have side effects that make the system less usable as a whole. If a word processor erased all the documents you had previously written in order to create space in which to save the one you were currently writing, you wouldn’t likely be very happy. The program is still acting as a tool (it helps you write and save documents), but it has a nasty side effect (erasing other files) which prevents you from doing other things, like revising work you’ve already done. This might seem like an extreme example, but it isn’t so far off from what some of the other “applications” out there will do to a system in the name of just getting a job done. For example, resource-intensive programs, like anti-virus software or Windows Vista’s content protection pipeline, can use up so much memory, processor time, and I/O that the system as a whole slows to a crawl, even though its processing power and storage are thousands or millions of times faster and larger than systems available 20 years ago. Yes, these programs are tools for accomplishing specific ends, which they attain (with varying degrees of success). But they impose such significant constraints on what other programs, and thus users, can do that they fail to be useful in an more global sense.

In the tool analogy, these programs are like a hammer that automatically pulls out a nail for every one you put in. You could argue that the defect in the hammer isn’t really the hammer designer’s responsibility, since the hammer is just a tool to aid in the task of pounding nails into a board, and it still does that very well. This would plainly be ridiculous. For a tool to be useful, it can’t just “blindly” aid its user in completing one task. Rather, part of what it means for something to be a tool is that it helps its user accomplish a variety of goals, often in tandem or as means to some greater end — say, building a house. (This is one reason we often speak of tool kits.) It doesn’t make sense to refer to software as “just a tool” if all you mean by that is that it makes one kind of task easier, perhaps at the expense of doing other kinds of work.

The UNIX world is much more sensitive to this broader concept of tool-as-part-of-a-kit. Many UNIX programs are designed to do exactly one thing, and to do it very well, without trying to be all things to all people. A huge part of what makes these programs so useful, though, is not their specialization to one task, but their ability to be combined with other programs. By combining the tools of the UNIX environment, users can easily complete new tasks that the system designers could never have dreamed of. It is the UNIX philosophy of providing both a set of useful, efficient, task-specific tools and an environment that facilitates combining those tools that makes UNIX the system of choice for a wide variety of computing tasks.

This brings me to another point where the “just a tool” mindset breaks down. Software is a very unique sort of tool: one that can produce other tools whose power are limited only by the user’s imagination. People who think software is only good for doing one pre-defined task at a time have had the wool pulled over their eyes. What makes computers so great for doing so many things is that they are programmable. You can balance your checkbook with a pocket calculator, but if you use a spreadsheet instead, you’ll be able to write programs that can answer new questions when you think of them (e.g., “how much did I spend on groceries between December and February?”) without too much more effort. If you write your notes using a text editor instead of a pen and paper, you will be able to search them, reorganize them, and reformat and print them in ways that pen and paper will never allow. Information-processing tasks in general are easier to do with a computer because, once you have the input data in a well-defined format, writing programs to manipulate that data in new and interesting ways is much simpler than performing those manipulations by hand. For this reason, software at its best is less like a tool and more like a whole machine shop: not only does it allow you to do certain kinds of things to start with; it enables you to build your own custom tools when the need arises.

In the end, it may be the case that some people prefer to operate their computers like drones, working through one pre-defined task after another, never stopping to think if they could do them better or more easily by thinking of their software in a new way. For such people, software truly is just a tool, and a rather blunt one at that. But the rest of us need not suffer this fate.

Advertisements

Written by whereofwecannotspeak

March 29, 2009 at 3:22 pm

4 Responses

Subscribe to comments with RSS.

  1. This is an excellent way of explaining the problem; I often have to explain to people that Windows was created by people who make their money off of limiting people’s ideas: user are users, they’re not programmers, in particular. However, as you say, Unix was created by people who knew that the users were smart enough to come up with new purposes for the tools they were building.

    Joel Spolsky said that Unix programmers only care about other programmers and Windows programmers care about “real people,” or something to that effect. What he doesn’t get is that users are supposed to be programmers, i.e. he’s right about who Unix programmers write for, but he’s wrong about who the users are!

    trashbird1240

    June 24, 2010 at 8:41 pm

  2. […] One of the most frustrating things I do in my daily work is wrangle with CSS. Trying to get a particular website to display correctly on multiple browsers and screen resolutions without ruining my HTML semantics can be an extremely painful process. Anyone who's ever had to do this knows the reason: browsers implement CSS differently, and sometimes (in the case of Internet Explorer) incorrectly and without any sort of sanity. The causes behind the … Read More […]

  3. It’s nice to see someone reading an old post, thanks!

    I think there are a lot of reasons why “users are users, they’re not programmers, in particular.” A big one is that “users” are encouraged to think of programming as a difficult, complicated task for experts. Proprietary software makers encourage people to think that way in part because it makes them more money, but also because that’s just how their systems are designed: programming is a difficult, complicated task for experts when you need a complicated IDE and “developer toolchain” to write code that does anything meaningful.

    One of the best things about Unix is that it’s so easy to write very small programs that can still save you, the user, an incredible amount of time and effort, without needing to become an expert in anything. I can’t tell you how many times I looked at the Bash or Gawk reference just long enough to figure out how to perform some trivial data manipulation, then ran it over a ream of data in less than a second. What a feeling of triumph that is!

    whereofwecannotspeak

    June 25, 2010 at 1:38 am

    • Definitely: I’ve had similar experiences writing one-liners. Just the other day I wrote a program in less than a minute that would monitor a simulation I’m running by sending me an email. It’s really nice to be able to do that; I have a hard time telling people that’s what I found so difficult about Windows. It’s not set up for flexibility like that, unless you’re a system administrator (is it even then?).

      trashbird1240

      June 25, 2010 at 9:16 am


Comments are closed.

%d bloggers like this: