A Word About Standardization

If you pay any attention at all to what people in technical circles (especially programmers) are saying, you will be familiar with the concept of standardization: everyone agrees to adhere to a particular standard, or the standards published by a particular body, and as a result everybody's stuff works together. To hear some of the zealots talk, virtually everything about computers, and especially software, should be standardized.

But that's not really necessary, or even a good idea.

What should be standardized in computers and software is exactly analogous to what should be standardized in the physical world. Specifically, it is not the things themselves that need to be standardized, but the connections and interactions between the things. This is equally true whether the things in question are kitchen appliances, part of your household plumbing, audio equipment, or computer applications.

Electrical and electronic equipment varies tremendously in terms of how it works inside and what it accomplishes, but it all interacts with other systems -- specifically, the power grid -- in pretty much exactly the same way. Setting aside for the moment what happens when you travel overseas, and heavy industrial equipment that runs off weird stuff like three-phase, normal stuff all runs off the same voltage (err, one of two voltages) and the same cycle of alternating current and plugs into one of a very small number of outlet styles. (Most things in the US plug into the same one style of outlet, but there are additional special styles for electric stoves, clothes dryers, and certain kinds of lighting. Other countries may have different exceptions. But even the exceptions are standardized: all clothes dryers in the US, for instance, plug into the same kind of receptacle.) If a device needs something different, the manufacturer includes (either inside the thing or along with it) a power supply or plug-pack that effectively makes the differences go away, or it runs off standard-form-factor batteries that can be recharged in a standard charger that plugs into a standard outlet. You can go to any store and buy any electric device for any purpose by any manufacturer, and it may do all kinds of weird stuff on the inside, who knows, but its interface with the power grid will be the same as for every other device. It doesn't matter if it's a computer, a blender, or an electric nose cleaner. You buy it, you take it home, you plug it in, and it Just Works.

Which brings me around to software.

Some things are pretty well standardized already. Network connectivity, for instance, is pretty much locked into TCP/IP. IPv6 has been coming for ten years, but at this point I am not convinced it will EVER replace IPv4, and there are no other contenders at all. There are some new application-layer protocols (e.g., BitTorrent), but these mostly are related to kinds of applications that were never standardized in the past. As far as things that have been around for a while are concerned (e.g., email), the standards are firmly entrenched. (The idea of an email-sending program that doesn't use SMTP has been tossed around in theory on a number of occasions, but trying to get anybody to use one is like trying to sell a life preserver that doesn't float.) The last time I can think of that established protocols were ditched in favor of new ones was when telnet and rcp gave way to ssh and scp. Even there, technically, telnet is still in use as a platform that other protocols (such as http and smtp) stand on top of.

Another place where things need to connect has to do with data. Internally, when a program is working with data, it can use whatever data structure it wants, whatever makes the programmer's job easiest. Nobody cares what structure the program uses internally, except for the people who maintain the program itself. But when the program goes to export the data and store it somewhere (in a file, in a database, wherever), now you have to consider the possibility that the user might also want to work with this data using other programs, and so you need a standard file format.

Programs that don't consider this possibility can end up creating data that the user can't ever do anything else with, and that severely limits their usefulness. There are lots of examples, but I'm going to pick on Microsoft Publisher in particular. Everything I say about it, of course, also applies to any other software that doesn't support any standard formats or other mechanisms for data interchange.

If Publisher could export its publications to a widely-supported format like PDF (or Word document format, or anything else that's widely supported), then people who wanted to send their flier or poster or whatever by email would have a way to do so. Better still, if it just used a standard format in the first place, then the user wouldn't have to go through the extra step of exporting: they could just attach the thing and send it. But Publisher can't do that. It only saves in one format: Publisher format. Nothing can open its files except Publisher. So if a user creates something in Publisher and asks me, "How do I send this to [someone]", there's only one answer I can give them: "Well, first, instead of Publisher, you have to create it in a program that supports a standard file format." Users do not like this answer, because it means the work they've already done has to be thrown away, but there's nothing to be done about that: Publisher simply does not provide for data interchange. (Copy and paste can be used to extract limited portions of a Publisher document, mostly the text, but that is usually not what the user put the most work into and is most eager to preserve.)

I call software like this Dead End Software, because there's no outlet: any data you put into it is trapped there, and there's no way to get it out. I strongly recommend against using such software for anything other than quick one-off work. (By "one-off" I mean something you're never going to need to refer to later, e.g., a Wet Paint sign. Even there you want to be careful, because a lot of times you think you won't need to refer to something later and then it turns out that you do.) It's a black hole, a final resting place for your data. Avoid, avoid, avoid.