I'm not mechanically inept, but my range of experience in home-maintenance tasks is not large, and mostly clustered around either calling in experts to do projects that most people would not undertake themselves, or things involving adding or removing a relatively small number of nails or screws. I recently repaired, rehinged and rehung two shed doors without difficulty, that's about my usual scale.  

So replacing our water-hemorrhaging "food disposer" (didn't these used to be called "disposals"?), which involved both plumbing and electricity, seemed like the kind of task that could descend into total chaos about halfway through, when some minor piece of the replacement apparatus proved incompatible with some intractable facet of the existing environment.  

Somewhat to my disappointment, the replacement went really easily. The old corroded hulk gave way without much complaint, the new one slid in with equanimity.  

The only interesting part of the task was tracking down the source of a strange trickle of water that appeared to be coming out of a wall where there was, as best I could tell, no plumbing at all. It turned out that the old unit had been leaking water into the flex-pipe for its own electrical cables! Not only is this obviously bad, but the constrained space made it an interesting topological puzzle to get the several ounces of fetid water back out of the pipe.  

But even if the tasks were ultimately simple and only trivially grimy, and probably a Real Man would have sucked the water out of the electrical pipe without even turning off the breaker first, I note for the record that in this upgrade I have gone from a third of a horsepower to three whole fourths, and I think we can all agree that that basically reeks of machismo.

My sister asked me, as part of her wedding ceremony, to Say Something About Marriage. I've been married for over two years, so obviously I have way too much insight on this issue than could reasonably be fit into the middle of an otherwise fairly compact service, but with some effort, and some help from my wife Bethany, I got the list down to twelve potentially useful pieces of advice. These probably aren't the most useful twelve pieces of advice, but I think they're better than nothing. As delivered at the wedding last weekend:  

1. Your world is getting bigger today, not smaller! More history, more friends, more possibilities. Marriage is not the end of the search, it's the beginning of all the searches that are more fun to do together.  

2. Be the guardians of each other's solitudes. Not only do you need to give each other space, you need to make each other space.  

3. No difficult conversations after 10pm. Not only is it harder to solve problems when you're tired, but at least half the time being tired is the problem.  

4. The Dutch principle of Total Soccer means that any player can attack when there is an opportunity, and any player can defend when there is a need. In Total Marriage you only have two players, so this is even more important. Both of you should be able to do everything your team needs. You'll have your preferences and strengths and habits, but if one of you goes down, the other one has to be able to cover.  

5. Wedding rings don't really come with magic powers. You will learn how to take care of each other one insight at a time. And even when you're not sure how, show up and you'll think of something.  

6. Headphones; separate closets.  

7. If you aren't already the world's leading experts on each other, you will be soon. It is thus your responsibility to be not only the world's biggest fans of each other's best qualities, but also the world's staunchest fans of each other's weaknesses and flaws.  

8. Get pets. By far the easiest way to remember that you have to feed your shared life together is if part of it comes and stomps on you every morning.  

9. No ultimatums. Ever.  

10. Travel. Surprise and challenge yourselves. It's easier to have a world together if you have a world to compare it to, and part of the fun of getting to know each other is putting yourselves, together, in positions where neither of you know what you're going to do yourself.  

11. Committing yourselves to one another is one of the most mature, responsible, focused decisions you can make. Balance it out by being immature, irresponsible and playful together as often as possible.  

12. When people, especially your relatives, offer you long lists of marriage advice, just smile politely and nod until they finally shut up.

Stars of Track and Field: Movies of Antarctica (2.2M mp3)  

I'm still buying CDs, mostly, but I'm no longer making any heroic CD efforts when downloadable versions are more readily available and cheaper. Centuries Before Love and War, the haunting debut album by Stars of Track and Field, is available from the iTMS right now, and will be out on CD in "spring 2007". Spring?! It's not worth my mental energy to keep track of its future existence for that long.

Damone: New Change of Heart (1.5M mp3) and Stabbed in the Heart (1.4M mp3)  

I think we've found a girlfriend for Waltham.

There's really no excuse for bad discussion-forum software anymore. The worst current standard choices are at least adequate, and nearly all of the ones that haven't wisely jettisoned reply-nesting at least have some view that minimizes its damage to the coherence of the discussion. Chowhound.com was a notable laggard until very recently, a vibrant community of food-lovers wrestling with a discussion system of approximately Mosaic's vintage that made mine look positively futuristic.  

Chowhound was acquired by CNet recently, who began their stewardship by sponsoring the long-dreamt-of reconstruction. There are a lingering issue or two, but it has gone from being the most technically antiquated stop on my daily information rounds to being one of the more pleasing.  

And even if you don't really like good food, surely everybody likes to read snarkily over-written complaints about minor affronts in restaurant service...

Venus Hum: Yes and No (2.0M mp3)  

I listened to clips of the new Venus Hum album on iTMS and decided it didn't sound that inspiring to me. And then I bought it anyway, because I didn't like not feeling inspired. So am I now loving it because I want to love it, or because I want to love more music again, or because I am just willing to let it affect me? Am I manufacturing responses, or disassembling obstacles to responding?  

I'm pretty happy about it either way. "Yes and No", in particular, makes me feel not only excited about music, but excited about technology in music. And even excited about technology itself, although clearly spending 8 hours a day being excited about technology in my new exciting-technology job makes me more receptive to opportunities to be excited about technology in other areas of my life.  

Ah, how clever and wishful of us to come up with whole different words for "cause" and "effect".

I'm not saying Keanu Reeves is necessarily a demon, I'm just saying that the scenes of him running and walking in movies don't provide any clear evidence that his feet are not hooves.

It was a joke when I wrote about DinnerPeace, the social-networking site for aggregating your dinner guests' food allergies, but I contend that the business prospects for that idea are not qualitatively different from those of PawSpot, a social-networking site for bartering pet-care.  

For further ridicule, see the comment thread at BostonWTF.

Somewhere, somebody needs a software system for something. Ordering sandwiches, maybe. It doesn't really matter, because software doesn't manipulate sandwiches, it manipulates information. So some programmer abstracts out the information-problems involved, and gives the abstractions names, and writes a program that operates them.  

Which hums along nicely for a while. The program creates blorfs, juggles them with admirable dexterity, and then copes ingeniously with whether they are sterkled or not. Only the programmer knows what blorfs are, exactly, and what it means to be sterkled, but the program knows what to do with them, and that's what programming is about.  

Except one day the program gets to the point where it has to actually assess the sterkledness of a specific blorf that represents some actual thing out in the world with an actual person attached to it, and thus arises the need for a User Interface. The programmer winces briefly, but then gamely poses the question:  


The user types something, and the program promptly crashes. Most of the subsequent changes to the program will effectively amount to this:  


If you speak your own language slowly and loudly enough, even uncooperative foreigners are bound to pick up at least the gist of what you're saying.  

But let's pretend the programmer gets past being irritated at the user, and realizes that they might benefit from some help answering the question. Help=instructions:  


Mysteriously, this doesn't really improve things. At this point the programmer reluctantly digs out that book about UI Design, and over the course of a painful few days produces this series of incremental and undeniable widget improvements:  








Calls to action are better than blanks, defaults are usually better than forced choices, radio buttons require fewer clicks than drop-downs when the number of choices is small, and checkboxes are even simpler when the choice is really binary. With any of the last three versions, at least, the program will be much happier. It needs an answer, and the widgets are such that it's going to get one no matter what the user does.  

Passing a usability test is a little harder than not crashing, though. The usability problem, of course, is that the user doesn't have any idea what a blorf is, or what it would mean to be sterkled, so these widgets could spin and invert and coruscate without ever changing their comprehensibility. Design is not the application of widgets to programming variables. At this point the programmer tracks down a product manager, if one can be dragged away from fiddling with PowerPoint transitions, and after some painful cross-purposes conversation they realize that the program needs to translate, for UI purposes, back into the user's vocabulary. Blorfs are, it turns out, sandwiches, or some meta-food-product abstraction that is, in this case, instantiated by a sandwich. Sterkle is a class of food-instantiation modifications, which in this case is the application (or non-application) of mayonnaise. Thus the original question is actually:  


Or, in our hard-won UI simplicity:  


This revision passes the usability tests with scores .724 higher than any UI the lab has ever evaluated, and the application is triumphantly deployed.  

By halfway through the first production lunch hour, the customer has threatened to insert the product manager's head into the panini press. The users (the customer's customers) like the software fine, but they hate their sandwiches. After a series of crowded and acrimonious meetings it is finally deduced that having mayonnaise checked by default has resulted in it being spread liberally on nearly every sandwich, because users are in a hurry and have just been clicking OK. So what the original question really amounts to, a lot of the time, is something much more like:  


All this time and work for a question that is almost always going to be answered one way. So we finally get this:  


And, after the addition of a fancy trend-analysis module of which the programmer is justifiably proud:  


Sadly, although the trend analysis is fascinating for the customer, the customer's customers are still pretty unhappy. If you like mayonnaise on your ham sandwich, it's not really interesting or helpful that the system thinks most people don't. The programmer wastes a month building an elaborate personalization system to keep track of exactly this sort of preference, but vexingly, nobody takes the time to create sandwich-option-preference profiles for themselves.  

Another month of arguing and thought produces the clever idea of automatically generating preference profiles for people based on their previous orders, which results in a lot more profiles, but the unfortunate feedback effect that screwing something up in your first order applies it to your second as a default, and the number of disgusting sandwiches is not going down fast enough. The customer, who spent years efficiently making non-disgusting sandwiches with no more technology than an order pad and a pen, is about ready to join the Luddites, even if they do want mayonnaise on their PB&J.  

If the programmer and the product manager are really lucky, one of them notices, before they lose the deal, two things:  

1. The customer knows a lot about making and selling sandwiches.  

2. The system is really intended to facilitate a conversation between the customer and the customer's customers, not the end users and the program abstractions.  

The program's task is thus, more properly, to help the customer represent their sandwich expertise in some way that allows the program to give the customer's customers a sandwich-ordering-and-eating experience that is, hopefully, more accurate and efficient than the no-tech version it is supplanting. Some knowledge analysis and sweeping re-architecture later, we get something like this:  


Notice that this isn't exactly the answer to "Is your blorf sterkled?"  

What Rudy (the sandwich guy's name is Rudy) knows, among other things, is that PB&J isn't a single sandwich, or a single combination of sandwich options, but a class of sandwiches involving a nut-related spread and a fruit-related spread. He has a version he likes to make, and some alternatives he knows people like. He'll make you a peanut-butter-and-mayonnaise sandwich on a spinach tortilla if you really want, but for that, for now, you have to come in and order at the counter with the rest of the freaks. The product manager keeps trying to sell him a drag-and-drop WYSIWYEat custom-sandwich-building module, but Rudy figures that if people wanted to build their own custom sandwiches, they'd build 'em in their own kitchens at home and bring 'em to work in lunch-boxes, and so wouldn't be ordering sandwiches from him. This online system isn't for people who aren't ever going to be his customers, and it isn't supposed to replace his counter. It's supposed to help his regular customers get their sandwiches without waiting in line as long, and to encourage his occasional customers to order more frequently, and to encourage his potential customers to click and try.  

The ordering system is also a menu, and it's supposed to make the sandwiches sound good. The drop-down alternatives, in fact, help demonstrate Rudy's sandwich knowledge, even to people who don't pick them. This interactive version of his menu (with similar treatment for all his other signature sandwiches) actually contains a lot more information than the one printed on the big board behind him, and thus has the potential to do a better job than the physical one of conveying not only his versatility but his expertise.  

It's also supposed to help him cope with the lunch-time crush with a little more anticipation and efficiency. His workspace out front is pretty small, and his kitchen in back is large, but if people are standing in front of you when they order, they like to see their sandwiches being made right there. Online orders not only can be turned around in 10 minutes instead of 1 minute, but they can be made back in the kitchen by Rudy's assistants, getting those out of his own way in both time and space.  

So, at the end of this long and arguably artificially obtuse case-study in design by myopic trial and error, we've come to the point where a life-improving software project should really begin: with the problem, and its aspects, and the context in which these aspects are aspects of a problem, and the characteristics that a solution in this context needs to have. Usually nobody (at least not the user, the customer, the programmer or the product manager) is going to know from the beginning exactly what the right solution should be, but everybody involved has some knowledge and some ideas and some dreams, and since those are ultimately both the cause and the goal of the project, they should be where the design process starts, and where it comes back to see how it's doing every time anybody wonders. Or, more often and even more critically, every time anybody notices that a little too much time has gone by without anybody wondering.