Tinkerable Software
This is a post I wrote for Software Testing and Quality Engineering magazine (now https://www.stickyminds.com) and subsequently published on a long-defunct site of mine. Laurent Bossavit asked that I recreate the web version. It was originally published in 2001.
Last night, I dreamt we'd just bought a new house, my ideal house: enough bedrooms, a nice lawn, fully furnished, the works.
The first thing I noticed was that some electrical outlets weren't in the right place. Not being handy with electrical work, I found an electrician in the phone book and called him in. He set to work. After a few minutes, he came to me with a puzzled look on his face. 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 I had another problem. I didn't want to watch television in the living room, but that was the only room with a cable jack. 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 not 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 over part of the lawn and put in a garden?) I decided to call it quits. I pulled my car into the garage – or tried to. To my weary lack of surprise, the garage was incompatible – unfixably 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 already awake.
Software should not be different
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 tinkerability from physical products. If our lawn mower breaks, we expect that the handy guy down the street can probably fix it, or that we can look up a small engine repair shop in the phone book.
It's a rare piece of software that gives us that. Consider web browsers and JavaScript. I want JavaScript on only when I absolutely need it. None of the three browsers on my main machine in 2001 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 back 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'd added to the toolbar, the browser would reload the page with JavaScript on and remember that JavaScript is allowed for any page on this site for
the duration of the browser session. It would also remember to ask me if I wanted to enable JavaScript permanently for this 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're thinking about tinkerability from the start. And there are many ancillary benefits: lower maintenance cost, contributions from a vibrant user community, more readily testable products.
A world of tinkerable software would be one with as many magazines about software product improvement as about home improvement or gardening or hot rods. I'd like to see that world.
Acknowledgements: Dick Gabriel and I came up with the idea of tinkerable software at the first Feyerabend workshop. Dick probably coined the phrase, and he had the catchy idea of a world where there were as many TV programs about tweaking software as about home improvement.
Drafts of the article were read by several people who gave helpful comments. Unfortunately, I only saved the mail from Noel Nyman and Harry Robinson, and I forget who else helped.