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.
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.