Working through abstractions

One of my recent projects has been the creation of an online directory of analyst research, which we'll be publishing imminently on the website. Like the existing events directory, it has been developed in Xara Modules, but it has been a longer project, partly because there will be more bells and whistles to this directory, and partly because there has been more material to be assembled before we can go live.

The project has been enlivened by the appearance earlier this month of a characteristically thought-provoking essay by Joel Spolsky, The Law of Leaky Abstractions. In computer science, an "abstraction" is a simplified representation of a process — for example, the neat hierarchies of folders you use to organize files on your PC, rather than having to directly deal with the scary detail of where all the relevant bits and bytes have been recorded on your hard disk. The more complex and sophisticated an abstraction is, then the more likely it is that there will be some inconvenient facet of reality that will make it work less well than it should, or in unexpected ways. Or, as Joel puts it, "All non-trivial abstractions, to some degree, are leaky."

I have been musing this point because it's highly relevant to Xara's connectable database modules, which are a remarkable collection of abstractions designed to allow non-programmers like me create our own database-driven website features. The form and reporter modules are sophisticated abstractions of the process of creating HTML forms and tables, and they work alongside database, query and database writer modules to create an abstraction of the underlying SQL Server infrastructure (there are some screenshots of these various features in some postings I did back in August and September to describe creating a sample application using the modules).

All of this is a remarkable undertaking, and it's inevitable in such an ambitious abstraction that there will be one or two of those leaks that Joel describes. For example, I would probably have a better understanding of the best way to assemble modules into applications if I knew more about how SQL Server works. In my ignorance, it's not obvious to me why, after adding an extra field to a database module, I then have to edit and reconnect all the query modules that link to it before they will output the contents of the new field ('well doh', I can hear all you database-savvy readers muttering to yourselves at this point).

But I don't feel that means, as Joel seems to suggest in his essay, that I should give up on Xara and go off on a SQL Server course before I touch it again. If it's something that I can't work around, I just file a help request and one of their patient support guys comes back to me and explains what's going on. Most of the time, I can work around the problem, and as an early adopter, I expect some things to fall short of the ideal at this stage. As time goes on, Xara will further improve the abstraction and enhance the usability so that many of these issues will go away. So whereas Joel seems to be discouraged by leaky abstractions because they have holes, I feel uplifted by them because I believe that sooner or later the holes will get plugged.