Tinkerable Software
In what ways should software be like a house? In a recent issue of STQE magazine, Technical Editor Brian Marick's musings about the concept of "tinkerable software" generated some interesting discussion about the very nature of software design. This week's column runs a portion of that piece so that our Sticky-minded readers can sink their thoughts into the concept.
Last night, I dreamed I'd just bought my ideal house-enough bedrooms, a nice lawn, fully furnished, the works.
The first thing I noticed was that some electrical outlets were out of place. Not being handy with electrical work, I found an electrician in the phone book and called him in. A few minutes after he set to work, he came to me with a puzzled look. The walls…well, what looked like ordinary drywall was, in fact, painted steel plate. Thick painted steel plate. He didn't have the tools to work with that, and he didn't know any electrician who would. I might try contacting the builder.
I realized another problem. The living room was the only room with a cable jack, but I didn't want to watch television in there. I'd wanted to put the TV in the spare room, but how would I run cable up there? Was I only allowed to watch TV in the living room?
While I was mulling that over, my wife came down from upstairs. Did I know that the picture frames were welded to the walls? It looked as if we could replace the pictures, but we couldn't move them. And any new pictures would have to be the same size as the old ones.
In my dream, I had a long and surprising day. (Who would have thought that it would be impossible to dig out part of the lawn and put in a garden?) Wearily, I decided to call it quits. I pulled my car into the garage…or tried to. The garage was incompatible-irreparably incompatible-with Fords.
I woke up screaming. After I realized it was all a dream, I showered, had breakfast, sent the kids off to school, and went to work on my computer. Within minutes, I was screaming again. But this time I was awake.
Software should not be different from houses
A situation like that of my dream would be intolerable in houses. We expect houses to be "tinkerable": ordinary people, not the original builders, can modify them in both small and large ways. Even those who don't want to tinker expect some degree of tinkerability from physical products. If our lawn mower breaks, we expect it can probably be fixed by the handy guy down the street, or by a small engine repair shop listed in the phone book.
It's a rare piece of software that gives us this tinkerability. Consider Web browsers and JavaScript. I only want JavaScript on when I absolutely need it. None of the three browsers on my main machine handles that to my taste. Two of them let me turn off JavaScript entirely. But when I hit a site that's unusable without it, they make me chase through menus to turn it on. Then I have to remember to chase through the menus again to turn it off. The other browser adds another feature: it can be set to query before running JavaScript. That's useless, because it pops up a dialog box for every page on the site (more than once if a page uses JavaScript in frames).
In a world where software worked as well as houses and lawn mowers, each browser would have a built-in scripting language (as well as ordinary Preferences dialogs). It would also have numerous "hooks" to which I could attach little scripts. One such hook would call scripts of my choice when a page was loaded. My hook would do this: the first time a page loaded, the browser would keep JavaScript turned off. If I pressed the "Reload with JavaScript" button that I had added to the toolbar, the browser would reload the page with JavaScript on and remember that JavaScript is allowed for any page on that site for the duration of the browser session. It would also remember to ask me if I wanted to enable JavaScript permanently for that site.
With any decent scripting language (such as Perl, Tcl, Python, Ruby, or Lisp), my script would be trivial to write. Granted, such tinkerability would probably require architectural changes to the browser. It would have to be divided into components with clear interfaces, hooks would have to be added, internal data structures would have to be modified so they make sense in terms of the external interface, and so forth. That sounds like a big deal, but it's not so hard if you think about tinkerability from the start. And there are many ancillary benefits such as lower maintenance costs, contributions from a vibrant user community, and more readily testable products.
A world with tinkerable software would have as many magazines about software product improvement as about home improvement or hot rods. And just as we can improve where we live and what we drive, we could improve the software we use. I'd like to see that world.
What are your thoughts? What kind of tinkerability would you dream up?