I originally wrote this as part of a kragen-journal post in 2001; this is a lightly edited version of part of http://lists.canonical.org/pipermail/kragen-journal/2001-February/000475.html
I've said several times that I prefer low-tech stuff, much to the shock of some of my co-workers; I'm not sure how to explain this adequately. The more I work with computers, the more I realize that complexity has hidden costs --- complex things are less reliable, fail in more unpredictable ways, are harder to diagnose problems in, are often harder to fix, are usually more trouble to keep running, are harder to change (especially to change without breaking), and are harder to get to work with other things. These alone are significant reasons to prefer a simpler solution to a more complex one unless the complex solution has significant advantages. But there's a nastier side to it, too. Complex things hide the intentions of their makers better. There's an interesting power relationship set up between a craftsman and the users of his work products: the work products are subject to the whim of the users, but also, the users are subject to the whims of the work products. This is a given in architecture: our mental state and behavior are powerfully affected by our surroundings; by manipulating people's surroundings, we can control what is easy and hard for them to do, and therefore, what they will do. So when you're interacting with an artifact, your control over your environment is directly limited by the extent of your control over that artifact. To the extent that you don't control the artifact, but are controlled by it, you are under the control of the artifact's creator. For example, I watched my ex-girlfriend Jamie deleting her spam one day. She used Outlook Express, which displayed each message as soon as she highlighted it in the message index. Because nearly all of her spam was HTML spam, it transmitted back signals to its senders (via "web bugs") that indicate that she had read it, and therefore that her address was a valid, deliverable address --- simply because she had highlighted it in order to delete it. I suggested to her that she should not view the spam before deleting it. Unfortunately, neither of us knew how to tell Outlook Express not to view a message when it was highlighted in the index, nor how to delete a single message without highlighting it; our ignorance made us powerless and subjugated her to the designs of the Microsoft engineers who wrote the program --- and, by extension, to the mentally crippled morality-disabled vomit-lapping spammers who exploit its careless intrusion on her privacy. This is a fairly innocent example; the only negative consequence is that her email address became less useful as time goes on, making it impossible for her to maintain very-infrequent email correspondences as an inadvertent result of a UI design choice. Not every harmful design choice is so innocent --- case in point: the version-to-version minor incompatibilities of Microsoft Office programs, which force you to upgrade your whole office, and which eventually render old documents unreadable --- and not every harmful design choice has such limited effects. As a result of many experiences like this, I do my best to use software that is as simple as possible. Maybe I'm too paranoid. Or maybe I'm just sensible, while many other people are blinded by the coolness of the stuff they're using. Only time and comp.risks will tell. I'd really like to work in an operating environment simple enough that I could actually read and understand every line of code, and flexible enough that I could easily change whatever I didn't like. It seems that it should be possible to build a mailreader, web browser, HTML editor, web server, GUI, and preemptively-multitasking OS, all in 100 000 lines of code or so. Viewpoints Research Institute has just gotten NSF funding to try to do this in 20 000 lines of code, but as I understand it, they are going to skip the web-browser part because they don't like the architecture of the web. I argued once that GUI programming is inherently harder than text-mode programming. Derek Robinson disagreed with me; he said that programming with the DOM in MSIE5, which one could certainly conceive as a kind of GUI programming, was far easier than programming with any GUI toolkit, or even in text mode, than anything he'd ever done before. I think he's right.
