Category Archives: frameworks

Traditional Values

I love the way given a heterogeneous audience a single bit of humor can be at once all kinds of humor.

Fun Fact about Common Lisp: standard Common Lisp has no networking libraries at all, but it does have a built in function to print integers as Roman numerals — using either the new style (14=XIV) or the old-style (14=XIIII) Roman numerals.

Dave Roberts) choosing to pass over it’s author’s fun but sarcastic invective and labels it sardonic irony.

In the good old days audiences were more homogenous. It was easier then for the humorist to know his target audience. That informs the question of why it is so widely presumed that nice people don’t do humor.

Power: Command v.s. Social

The label passive aggressive is oft ascribed to others but rarely subscribed to. When you deploy this label your accusing the other side of acting both with a hidden agenda and out of weakness. Note that the accusation of a hidden agenda is usually an indirect way of admitting that you haven’t a clue what the other side is on about. Notice also that the accusation of aggressive is a step toward admitting that the other side has power. Negotiating power. The exaggerated language is a failed attempt at self deprecating humor. Humor about the of the fear this realization has engendered.

A black and white model of negotiation might hold that it’s what you do when your not acting. In that characterization it becomes the opposite of acting, i.e. passive.
But real negotiation is work. The work of negotiating is the work of finding a common understanding. That search involves uncovering workable models of the other sides agendas.

One frame to shovel all this into is ‘coordination problems.’ Some coordination problems are solved by command control; which is typically viewed as masculine. Some coordination problems are solved by emergent behavior arising out of common cause (pool of common practice). This is often called community and typically viewed as feminine. Of course all the real systems and interesting systems are in the middle space between these two fantasy worlds.

Power is found in both these systems at their network hubs. Which is obvious in the tree topology of the command and control hierarchy; and even in the more complex variations on that where different dominions of authority (say: management, engineering, marketing, pr) are overlaid. Efficient, stagnant systems may have no conflicts to be resolved at these hubs; but that’s rare. The function of the nodes in the topology is to both execute the ritualized parts of behavior but more interestingly to resolve conflicts – i.e. to do the negotiation. In a hierarchy this puts the guys in the middle nodes into interesting role of bridging between two differing world views. Which opens them up to the accusation that they are two faced.

In the community coordination systems the network hubs draw all their power from their role as negotiators; though that’s rarely the term used. Social networking is another name used. The powerful role in these systems works off the energy created by the diversity of world views found across the hubs contacts. Moving information and resources around to create common cause. Telling engineering about what marketing has discovered. Connecting somebody in manufacturing with somebody in engineering that might know somebody who can resolve the problem de-jour. Like the middle manager in a command and control hierarchy the hub can be accused of unclear loyalties.

Of course this is all terribly over simplified. But the male-bossy-hierarchy model is more likely to see the female-chatty-networking as passive aggressive.

Engineering as a Profession

Some more notes from my reading on proffessionalism.

Engineering is just different than the three archtypical professions Law, Medicine, and the Priesthood.

1. Knowledge base changes faster
1a. Reduces opportunity and value of standarizing practice patterns.
1b. Reducing the advantage of mature practitioners.

2. Work products are more tangible.
2a. Can be inspected by third parties
2b. Market performance plays much larger role in quality assesment.
2c. Services more easily mediated (i.e. thru middlemen)

3. Origins in market success, not failure.
3a. Origins in upper class entrepenurs.
3b. Exagerated: extent of both Consultancy and Entrepenurship.
3c. Conflicted loyalities: states via public goods, commerce entrepenurship.

4. Engineers are "Salaried Professionals"
4a. More like hired labor than service providers.
4b. Consequence of 2c.
4c. Fact at odds with 3b.

Some of this varies depending on which branch of engineering you look at. For example civil engineers often build public goods for the state and to a degree their platform of knowledge is more durable than say software engineers who are often tied to entrepenurial capital and thier platforms are in continual flux.

I think it’s quite telling that engineering as a practice, particularly in America, spun off of the upper class and it’s practitioners tend to presume they still have the power and mobility of members of that class inspite of the fact that the majority of engineers are hired labor working for large firms.

I’m amazed at how much consequence flows from the tangible nature of the work compared to the three professions mentioned above. These tangible objects can be tested in two ways. One very micro: another professional or the end user can evaluate them. The other is very macro: the marketplace can evalute them. The market is, of course, a swarm of idiots so this distinction is huge.

The other consquence of having working in a profession with a tangible work product is that third parties can buy and sell it. Politicions can sell the roads, tinmen can sell the aluminum siding, marketing can sell the software.

Egg Drop Programming

… asked us if we ever intentionally got lost in a town, perhaps a town new to us, so that we had to learn the place in order to get back to a place we knew. Several people nodded vigorous agreement, and one guy noted that he and his colleagues use a similar technique to learn a new legacy code base. They call this air-drop programming. This is a colorful analogy for a common pattern among software developers. Sometimes the best way to learn a new framework or programming language is to parachute behind enemy lines, surrender connection to any safety nets outside, and fight our way out. …

Took that from here.

There are varients of this technique, walk-about, year abroad, home visit.

My techniques of this kind aren’t as random as that sounds. For example in a city I will find the old train station, park and then walk in the direction that seems to go down hill economicly. Or in code I will find the error logging or memory management and then work backward up the call tree, at first breadth first and then selectively depth first. Sometimes I look for the chinatown, or the I the center of what was the city’s primary industry 30 years ago. Often it’s good to look for the place where a bloom of new code occured, try to figure when it happened, and then look at the borders between it and the older code.

Now: Get lost!

Design Traps

I very much liked this list of design traps. It’s taken from the middle of a paper (pdf) by the always brilliant Phil Agre. In that context Phil is talking about the problem of designing a technology rich system that will presumably transform an existing large social institution, libraries. But it’s a really good list for all those situations where your designing a system that is expected to transform behaviors in an existing institution.

The trap of …

  • … presupposing standards
  • … deriving political consequences
  • … automation
  • … assuming rapid change
  • … command and control computing
  • … inventing a new world
  • … blaming resistance
  • … assuming away intermediaries
  • … technology
  • … designing for a limited range of cases
  • … presupposing transparency

I want to chew on these a bit, so hopefully this posting will get revised over time. These are my restatement of what Phil writes, which is of course much better.

Standards: Never presume things are interoperable. Standards are hard work and only rarely emerge. Let’s repeat that, they rarely emerge. Most systems are heterogenous aggregations with much, if not most, of their substance in the glop that inter-connects their parts.

Politics: Never assume your technology leads to your desired political outcomes. This one’s facinating because consensus that the work at hand is creating a social good is always a constructive driver of large change. It maybe a near certainty that one will get piled on. But! Systems design is a thicket of unintended consequences. This one’s very entangled with the standards, hierarchy and intermediary traps.

Automation: Designs reshape roles, they don’t meerly automate existing chores. At first blush you may look at your system as lifting a burden off some actor in the old system; but it is useful to realize that in fact you are negotiating the nature of the work. This is often why system designers tend to automate other people’s work, not their own. This kind of negotation is politics; not in the big idea sense but the complex local politics of successfully integrating diverse points of view and need.

Rate of Change: Chips, communications, and network effects can grow amazingly fast; meanwhile social, physical, and economic systems are be very resilient, durible, and slow to change. System design takes place in the huge space between. Any assumption you make about real rate of change should be viewed with extreme suspicion. Note the irony in the standards trap mentioned earlier: assuming standards, and hence interoprablity, is the presumption that there is a stable durible social foundation you can build on.

Hierarchy: Phil’s argument here is that historically computer systems drew most of their funding from hierarchtical organizations both commercial and milatary and that has created a bias in our tool kits and mind sets. True. But that’s not the only reason why edge emphasising design patterns are so scarce.

… more later

Phil’s paragraphs on these are at the tail end of section two of the paper (pdf).

The Hedgehog and the Fox

Here is a another really delightful metaphor for the power-law dialectic between the elite and the long-tail.

In his essay on Tolstoy’s philosophy of history, Berlin starts with the fragment of the Greek poet Archilochus, “the fox knows many things, but the hedgehog knows one big thing.” The conventional interpretation of this proverb is that the fox, for all her cunning, may be defeated by the hedgehog’s one defense. Berlin suggests the metaphor may also be used to highlight one of the important differences among basic vision of life held by different thinkers and writers.(4) On the one hand there are those who believe that there exists a single, universal organizing principle in terms of which alone all that they are and say has significance. On the other side of the divide are those whose beliefs are scattered or diffuse, moving on many levels, seizing upon a vast variety of experiences and objects for what they are without seeking, consciously or unconsciously, to fit them into any one unchanging, all embracing, unitary vision. The first kind of intellectual is like the hedgehog, the second, like the fox. Berlin suggests that Dante, Plato, Lucretius, Pascal, Hegel, Dostoevsky, Nietzsche, Ibsen and Proust are, in varying degrees, hedgehogs. Herodotus, Aristotle, Montaigne, Erasmus, Moliere, Goethe, Pushkin, Balzac, and Joyce are foxes.(5) Berlin readily acknowledges that, like all over-simple classifications of this type, the dichotomy becomes artificial, scholastic, and ultimately absurd.(6) Yet he argues that because the distinction captures an important insight, it provides a useful starting point for genuine investigation.

There is a small excerpt from Berlin’s essay here.

The Five Great Philosophies of Life

The book I was looking for was not on the shelf, but this was a few books down. The original copyright is 1904. Prudence Hyde renewed the copyright in 1938 by Prudence Hyde. The five great philosophies?

  • Epicurean Pursuit of Pleasure
  • Stoic Self-Control by Law
  • Platonic Subordination of Lower to Higher
  • Aristotelian Sense of Proportion
  • The Christian Spirt of Love

But then I’m sure you knew that. The author was William De Witt Hyde, a president of Bowdoin College. (Amazon)

Space: the API

My car’s check engine light came on. Being both modern and a cheapskate I found the online community where Passat owners hang out. My old car there had a secret pattern of key turns and button pushes that would cause the car reveal engine’s fault. I was hoping for something similar.

But car makers love to keep things secret. German car maker are more secretive than Japanese makers. So it is verboten for Passat owners to know what lies behind their check engine lights. My fellow owners showed me a way. Autozone will read out your check engine codes for free. Autozone has solidarity with those who to fix their own cars.

The man at Autozone climbed under my steering wheel and plugged in. He and I copied the codes down onto a peice of paper. He then placed his finger just under a large yellow button on the read out device. He held it up, away from his body, toward me. He turned and gazing away into the distance. My eyes followed, a large warehouse sat on the far side of the parking lot. He said speaking into the empty car. “If it’s still under warrenty we can’t press the big yellow button. That clears the codes.” He paused, gazing more closely at the warehouse. “I” “Can’t push the yellow button.”

The inside of Autozone is full of gadgets to hack your car. An entire asle of things that plug into the cigarette lighter. A wall of steering wheel covers. Two racks of things to hang from the rear view mirror. Devices that clip to the air vents on the dash board.

I once built a store front. A place where developers could sell their wares. The developer products all plugged into an existing product. Our product. We called it the developer’s market place, it was a way for the developers to reach our customers, our product’s users.

As mentioned car makers like to horde their options. They like to sell you the radio rather than relinquish that option to some random 3rd party. So generally auto makers are not very big on open APIs. I suspect they grumble about that cigarette lighter.

But standing looking at the Hawain shirt steering wheel covers at Autozone I had an epiphany. How little it takes to create an API. How small an affordance. The convex shape of the steering wheel, the latent hook on the rear view mirror, the trickle of electricity in the cigarette lighter.

A few days later I was listening to a talk by one of the dudes who have been hacking on the Prius. He throws up a slide showing the floor under the hatchback. There’s a panel. The panel is removed in his next slide and there is a small shallow space. Just a few inches deep. Useless really.

But, immediately I knew. That empty space! Full of latent energy. Waiting for their hack. Drawing them in. “Fill me!”

What happened? Why did Toyota leave that space? Did they actually know what they were doing. Did they know that empty space is an open API for developers? It’s not as hard to create open APIs as you might think.

Ships in the Night

There is a delightful pattern in collaborative design I usually label “ships in the night.”

Two designers posit different solutions to the problem. Mr. A advocates plan A, and Mr B advocates plan B. They debate the merits of their respective plans and then adjorn.

During the night Mr. A thinks about the merits of plan B. Mr. B thinks about the merits of plan A. They both begin to come around to the other guys position. They think how noble it would be to give in.

They also puzzle a bit on the cost of their plan. Mr. A begins to think about how hard his plan really is. Mr. B thinks about his plan’s complexity. They both begin to become a bit fearful of their plan. They think what a burden it would be to own the plan, particularly one that was in dispute.

The next morning they return to the discussion to discover they have switched sides. Ships in the night.

Hidden Agendas

The other day I said to somebody that “it’s a political process” and he replied “you mean he has a hidden agenda.”

I think the word politics names the process by which many parties with widely divergent world views attempt to find common ground so they can get something done. That search is the key. So when I say “political process” I mean that the parties are still searching; but that they are still in the same room trying.

Lots of people hate that room for quite a laundry list of reasons. First off it appears that nothing gets done in there. Attempting to find common cause is what gets done in there. It’s risky hard work. There is huge risk that you spend resources and fail to find common cause. There is risk that spend resources, find what you think is common cause, and then latter you discover it wasn’t strong enough to stand the buffetting of future work. Always there is the risk that the guy in the room won’t be able to deliver his constituency. All that raise the risk that the game your playing is a short term rather than a long term one; which only makes the possiblity of defections higher.

If people all see the world in the same way then you wouldn’t have a problem you wouldn’t need to go into a room and try to find some common cause. In such rooms the puzzle is to figure out what the other guy can see that you can’t. In retrospect I find it amusing to realise that the difficulty of that work makes it always appear that the other guy is hiding something. It is rare that people know what they know. It’s even more rare that they know what you need to know.