More Reflections On Software

A few days ago abi sutherland blogged about how artists and software designers are not in control of the outcome of their work, with particular application to devices and contrivances that are intended to be extended and customized by end users. That pushed some buttons in my head, and I posted a comment on the subject, which I've extracted below. I have some more to say on the subject, which I thought only fair to say on my own blog, so more posts will follow at less than the usual irregular intervals, I hope.

Oh-oh, you hit one of my current hot topics. I feel a rant bubbling up; I must take on my Aspect and wield my Attribute.

The system I'm working on now has some major design problems because some fundamental issues about valid character sets and the use and communication of metadata mixed with data weren't addressed at all. These things are central to building a system that's flexible, extensible, and allows mashups to be created without knowledge of the system internals (preferably without any sort of deep technical knowledge at all*).

I've been thinking about the sort of design criteria that are important in software that can meet these requirements. Here are my first thoughts; I'll continue on my own blog as they develop, but you got the juices flowing now, so I'll begin here if you don't mind.

1. Quoting is vital. It must be easy to encapsulate any string of valid data (e.g., text characters, images, the basic vocabulary of a web page) so that the system can treat it as an opaque object except where the data really is meaningful. It shouldn't be necessary for an admin or someone extending the system to deal with escaping characters significant to parts of the system, like '&' and ';' in HTML, or ''' or '"' in SQL literal strings, or (oh, help me Noshabkeming!) spaces in filenames. Always remember that a filename can come from most anywhere.

2. Metadata is data to any system that doesn't have to process it. Opaque objects have to remain opaque unless the software really needs access to the insides. Accidental access is a good creator of truly diabolic bugs. I created a test case yesterday with an object whose name contained an apostrophe. This caused the web application that read the name from the database to crash.

3. Objects shouldn't have to have knowledge of each others' lifecycles. If an object is created in one system and another system creates another object to collaborate with it, then either the first has to exist for as long as the second needs it (and that's often not easy or even possible to guarantee), or the second system has to make sure that it copies everything the second object needs from the first, without creating any issues of staleness of the copies during the life of the second object (and that's as close to an intractable problem in a distributed system as I know about). Anybody who's ever slaved over request-scoped webapp variables has been bitten by this one.

Akk! This is growing from a screed into a tome; not what I intended. I'll stop now and go get ready for work. Let me know what you think of this.

* Librarians are technically-oriented, but don't necessarily have specific knowledge about the administration of software, especially web-based systems. The manufacturing workers who administrate my system are not technically sophisticated at all; they're bright people, but don't have technical educations, so they're not familiar with some basic concepts that would make it easy for them to create a mental model of what they can do with the software. And I can't expect to train them in something that's irrelevant to their jobs.