Cultural wisdom

Engineering is the real culture of our age. That, and maybe the movies. The movies play the role in our time that opera played in the 19th Century and drama in the 16th: a synthesis of many arts, both visual and otherwise, terribly expensive to create but economically viable because of its broad popularity. The movies form our high "culture" in the humanities sense; but our real culture in the anthropological sense is engineering.

We often forget this, because the engineering culture is usually expressed, not in words, but in things. We are surrounded by thousands upon thousands of artifacts whose forms, functions and materials are shaped by engineers, and these artifacts in turn shape our lives in ways beyond reckoning. Undergirding all of this stuff is a vast and ramified human system of engineering values and practice, and it is this system that I mean when I talk about "engineering culture". Much of the practical wisdom of our age is bound up in that culture of engineering. Like many forms of cultural knowledge, it often exists in implicit form, shared by the engineers themselves as an unspoken "common sense". But I'm always happy when someone discerns and formulates a part of this for the rest of us.

My brother -- the space engineer brother, not the computer guy brother or the Lutheran theologian brother -- has occasionally put some engineering culture into words. I particularly like two of his maxims. Call them PW's Rules of Optimization:

1. Sometimes it is not optimal to optimize.
2. You can only optimize one thing at a time.

Rule 1 means that it is not always worth the time and effort to figure out the "best" way to do something. You find something that works, do it, and stop worrying. Severe optimization is really only appropriate when you are conserving some hideously expensive resource. Thus, when designing a spacecraft, you really try to optimize the mass of your equipment, because it is so expensive right now to launch a kilogram into orbit. The same sort of careful husbanding of resources used to apply to computer programming. You'd take pains design your program to use the least memory and processor time, and you'd agonize over trade-offs. But nowadays, except in some very high-end applications, computer time and memory are too cheap not to waste.

I actually think that Rule 1 is a deep and generalizable insight into life. Rule 2 may be even deeper, because it is less obvious. Suppose I am designing a new computer, and I want to make it as fast as possible. Well, it turns out that there are several measures of "speed". I can optimize the clock speed of the processor, or the speed of floating-point operations, or the bus bandwidth, or the disk access time, yada yada yada. It is highly unlikely that I'll be able to optimize more than one of these with a single system. There are always trade-offs.

To cope with this, I can take one of two approaches. I can try to come up with a single "figure of merit" that captures what I really want. For instance, this is what the LINPACK benchmark does, for instance -- essentially, it is a single function of all the different sorts of computer speed. Many figures of merit are a bit hokey -- after all, my computer may not be intended to do LINPACK calculations all day long -- but (remember Rule 1) sometimes you just pick something reasonable and go with it.

The other approach is to adopt a reasonable constraint for all but one of the variables, and then optimize the unconstrained one. This is what we do everyday when we say things like, "I want to buy the largest-memory MP3 player that costs less than $200." Here you have constrained the price and wish to optimize memory. Note that you can have as many constraints as you like, so long as you don't over-constrain yourself out of existence. But in the end you can only optimize one thing. And life works best when you know what it is that you are optimizing.

Here is my zeroth-order theory of economics. Each of us makes choices, like an engineer, subject to the constraints of our own lives. Each of us therefore acts as if we were optimizing something. But of course, we can only be optimizing one variable. That variable is what we (individually) mean by "value". The reason that economics works at all is that, because of Rule 2, "value" can ultimately mean only one thing for each economic agent, despite the complexity of the trade-offs we make. The reason that economics does not work all that well is that we don't really act like idealized engineers, because none of us has a fully defined consistent universal concept of "value". Luckily, we can get along without it. That, of course, is Rule 1.

Like I said, I think this business runs very deep. I am half-convinced that Boethius's discussion of the nature of the Good in The Consolation of Philosophy could be recast in terms of Rule 2. (As an aside, I would rank this as one of my ten all-time favorite books Weird, but true.) But perhaps it would be going a bit far to try to connect modern engineering practice with the insights of a 6th Century philosopher and theologian. Especially here at the end of a post.