Category Archives: threes

Three – or the one more rule.

One essay in Stephen Jay Gould’s books made a deep impression on me, it was a rant about the dangers of a dialectic argument. Individuals of this species, dialectic arguments, like to join together into herds. The moment one enters the room you can expect a stampede of analogous arguments to show up soon. They also have a clear pecking order that gives lazy groups a well worn path they let the conversation take.

For example. Start to discuss the trade off of speed v.s. quality. Map speed to man, and quality to women. Map man to rude, and women to polite. Map rude to bad and polite to good. Map bad to evil, and polite to noble. If you do this really fast it’s amusing; but built up slowly it leads to nothing but trouble. The escalation is one obvious problem. Another less obvious problem is the forcing of unlikely bed fellows. For example slavery for/against used to be aligned with democrat/republican but then labor/capital is aligned democrat/republican; that wasn’t stable. Or to take another example: secular/religious doesn’t mix well with labor/capital unless you force secular/religious to align with independence/hierarchy – not a very natural mapping either. Strange bed fellows. The strangeness gets magnified as the polarization increases.

The wealth of well worn dialectics tends to make it easy to fall into these trap. To help counter that in my own thinking I’ve been seeking a a catalog to three sided things. For example geographic/political ones – New York, New Jersey, Connecticut; or England, Scotland, and Wales. Sooner or later I’ll get around to pulling together my current collection and posting it.

Moving the discussion from two to three has, of course a more general form. For example now when ever I see a list, like hardware, software, services, I ask “Can I have another?” Solutions?


I’ve always enjoyed being a smart aleck about dialectics; injecting a third into the midst of the mud wresting that others like to do.

So the middleman in the midst of buyers and sellers is partially of that kind.

But I think’s helpful to spend some time aggregating the tools to work on problems in a less polarized manner. Toward that end I’ve been baiting various groups for examples of sets of three. I’d prefer ones that bring rich metaphors along with them. The three colors for example do that.

One example was delightfully way to do this is illustrated by: GM, Chrystler, and Ford; the three big car makers in the US. If you have a concentrated industry you get a small number of big players. That’s one of the extreme power-law cases and of course you can then go find lots of other power-law sets and pop off the top three.

For example english from here.

  • Spoken: the, I, you
  • Written: the, of, and
  • Nouns: time, year, people
  • Verbs: be, have, do
  • Adjectives: other, good, new
  • Adverbs: so, up, then
  • Pronouns: it, i, you
  • Determiners: the, a, his
  • Determiner/Pronouns: this, that, which
  • Prepositions: of, in, to
  • Conjunctions: and, that, but
  • Interjections: yeah, oh, no

“Yeah”, “Oh” … “No!” That’s practically the example i started with.

Diagnostic Typing

One of the dialectics in computer science is between dynamic and static typing. Dialectics are like professional wrestling. Cheap fun. But, they leads to category blindness. So let me blather a bit about a “third way” that I call diagnostic typing.

At one point in my career I spent a few years deeply committed to the static typing camp. The height of that experience was an amazing day when we successfully linked, for the first time, a huge complex program. It consisted of hundreds of thousands of parts written by numerous authors and code generators. It worked! First time! Getting to that point had required tremendous labor, since the static type checking demanded by the language we were using had forced us to fix lots of stuff that might have been left for latter. At that moment it seemed worth while that we had deferred so much immediate gratification for so long.

Late in the project we had some really amazing bugs. Bugs that took weeks and teams to fix. Fun bugs with long interesting stories to tell about each of them.

During that later period I found my self writing what I came to call diagnostic typing code. This code would work to prove a complex declaration about the nature of a data structure. These declarations were put forward by the team members. For example somebody might say “All the records of type A are in the dictionary D.” and then somebody else would say “Ah, I thought the core set of those aren’t in the dictionary.” At that point I’d go off and write some code to to check if these declarations were true. It was fun because the truth was almost always much more complex than anybody thought. The bugs were all around the edges of these.

So the dialectic between dynamic and static typing is actually a kind of layered thing; with at least with three layers. Static, Dynamic, and Diagnostic. Static type checking is done at compile time. Dynamic type checking and dispatching is done at runtime. Diagnostic type checking is done intermittently; usually in response to a demand or a fear. It was extremely valuable to become explicit about some of the declarations that had been implicit.

Diagnostic type checking can be very very expensive. That makes it a lot of fun! It lets you can write all kinds of assertions about your program that would never be practical to check or enforce at the compile or runtime. You can get out the big guns: graph theory, statistics, coverage, grammars, budgets, spelling correctors. For example: all the window components form a strongly connected component via their child/parent arcs. For example: the elements of this hash table are uniformly distributed. (As an aside I don’t think I have every found a hash table that was well behaved in the wild.)

One of my favorite examples. This isn’t just for data structures you can do this on program traces too. Back in the 1970s somebody at CMU wrote a paper about using the ideas from language grammars to declare the patterns over calls on class instances. Things like: x:foo<-create(x); {open(x); {update(x)}+; close(x)}+; destroy(x)}*. In a later life I would sometimes write code to diagnostically check statements like that by using the tracing facilities in Common Lisp.

I wrote a lot of this diagnostic typing code for the persistent store using prolog. I would dump the entire persistent store into a suite of prolog assertions and then write the diagnostic typing declaration as small prolog programs who’s execution would prove or disprove these declarations. While that found a lot of very very subtle bugs I found it more fascinating how it raised raised the level of discussion about the work.

This kind of approach will, I suspect, become more common real soon now. So much of the data sloshing around on the net is full of surprises that diagnostic typing declarations would reveal. Moving the data across organizational boundaries creates a demand for tools that can frame the discussion between the parties.

One of the reasons I’m suffering a fit of enthusiasm for RDF is how it appears to offer a normal form, much as prolog assertions did for me in my previous experience, for just this kind of problem solving.

This trio: static/dynamic/diagnostic typing are all about shifting around the work, the trust, and the gratification. Don’t overlook the gratification. There is a lot of fun to be had in diagnostic typing approaches. I doubt you can write down all the declarations about the data before it starts flowing. Why defer the fun of flow?

How to have a Fiasco

Some people pick a question, usually in graduate school, and then spend the rest of their life puzzling out an answer to that question. Lately I’ve been reading some of Irving Janis‘ work on decesion making. The question he seems to have asked early on was “How did these smart people make those choices that lead to this fiasco!” In his book Groupthink he looks at the fiasco of Pearl Harbor, the crossing into North Korea in the Korean war, the Bay of Pigs, and the escalation in Vietnam.

This turns out to be an excellent question to build a career around! No shortage of fiascoes to study. No shortage of people with money scared to death they are on the road to a fiasco. Better yet there is no shortage of people convinced that those around them are on that road.


Making a decision is embedded in a context that aids and constrains the outcome that gets generated. This cartoon highlights three aspects of the context. In this view of the problem solving we ignore the actual problem and look only at the resources brought to bear on solving it.

Irving establishes a straw-man he calls “Vigilante Problem Solving.” That’s the good kind of problem solving and it outputs good decisions. The failure modes are framed as “taking short cuts” or other resource limits that preclude the good kind of problem solving.

Here’s a little enumeration of constraints on the quality of the problem solving that lifted from his book Critical Decisions along those three dimensions.

  • Cognitive Constraints
  • Limited Time
  • Perceptions of Limited Resources
  • Multiple Tasks
  • Perplexing complexity of the issue
  • Perception of lack of knowledge
  • Ideological Commitments
  • Affiliative Constraints
    • Need to maintain: power, status, compensation, social support.
    • Need for acceptability of new policy with organization
  • Egocentric (Self Serving and Emotive Constraints)
    • Strong personal motive: Greed, Desire for fame, etc.
    • Arousal of an emotional need: e.g. anger, elation
    • Emotional stress of decisional conflict

    The constraints lead to failure modes. By picking apart the historical record of the various fiascos he has collected a library of these failure modes. The contribution of the Critical Decisions book bridge between the model of resource limits and various failure modes. It’s a bridge from a general model to the stories in his collection of fiascos. Each bridge is a template that outlines a given problem solving technique and then highlights how that problem solving technique goes bad.

    Here’s an example. A template for a problem solving technique that plays to a person or organization’s strengths an augments those with reasoning by analogy:

    We have cliches to dis this technique. “Searching where the light’s bright.” of “If you’ve got a hammer everything looks like a nail.

    But this is a fine problem solving scheme. We all use it. It plays to our strengths and let’s us leverage our organizational muscle. It will only lead to a fiasco if the problem fails to fit the available SOP. Things fall apart when the organization starts getting highly invested in the analogy between a nail and screw. Then they start engaging in various thought stopping processes and begin singing in unison: “I gotta hammer, I hammer in the morning…” For a while they think they are happy!

    Vigilance is hard work.

    Governance of Overlapping Groups

    There are very very few works that directly address how to control the slope of the power law curve. Clay Shirky’s essay on inequality for example. Michael Porter’s list of things that keep an industry fragmented is another. Both of those enumerate tools that create niches, barriers and membranes. Each one of those tools deserves it’s own book – or at least a page in a wiki.

    Rereading Clay’s essay I notice that one of the techniques he mentions is to reduce the amount of heterogenity in the system; the example he gives is hierarchy – i.e. the millitary. I’m reminded that hierarchy is one of the common solutions to the coordination problem around collective action.

    It’s a cultural truism that centralized hierarchtical system often run amuck and become the prime source of abusive of power and severe inequality. The lession embedded in the power law story (i.e. appreciating that homogenous networks spontanously create power-law distributions) is: “Hold on homogenous creates hubs, and those hubs have power, and that power is just as susceptible to abuse as any centralized hierarchtical design.

    Rereading Clays essay this week, this week, I’m struck by the way that firms often attempt to temper the problems hierarchy creates by creating multiple overlapping hierarchies; e.g. functional organization/proffesional hierarchies for that overlap project/product-line organization.

    As a move in the game of systems design it provides a kind of check and balance. A means of auditing and oversight. Additionally it helps in creating safe niches for key activities. Inside those niches various kinds of skills, resources, public-goods can emerge.

    I have model, totally ungrounded by the facts, that as the population grew the three spheres of commercial, civic, and religious activities broke apart. When people talk about the seperation of church and state they are speaking of that historical event – but just as critical was the way that commerce began to become distinct from the creating of public goods that is the work of the civic sphere.

    Governance of such tangles of overlapping groups is a facinating mess. The coordination problems run deep; as they must if the groups are to remain distinctive.

    A friend and I got to wondering yesterday if there are any examples of systems were tribe A elects the elites of tribe B and visa versa? You can see plenty of cases where a dominate tribe appoints the elites of a subordinate tribe. You can seem plenty of places where one tribe has numerous moves where it can check and balance the moves of other tribes.

    It would be a very interesting university where tenure choices in each department were always made by other departments, for example.