Gumption Traps

I enjoy working here more than any place I can think of, but that doesn’t mean it’s always hunky dory.  The last couple of months have been filled with gumption traps.  I first read about these in Zen and the Art of Motorcycle Maintenance.  If you haven’t read it, it’s an allegory about the nature of fitness and the design of functionality disguised as a personal account of a motorcycle, all couched in a modern version of a Platonic dialogue. 

Background

Here are the important things to know for this blog entry.  All quotations are from the book unless otherwise noted.

Quality

Quality—you know what it is, yet you don’t know what it is. But that’s self-contradictory. But some things are better than others, that is, they have more quality. But when you try to say what the quality is, apart from the things that have it, it all goes poof! There’s nothing to talk about. But if you can’t say what Quality is, how do you know what it is, or how do you know that it even exists? If no one knows what it is, then for all practical purposes it doesn’t exist at all. But for all practical purposes it really does exist. What else are the grades based on? Why else would people pay fortunes for some things and throw others in the trash pile? Obviously some things are better than others—but what’s the "betterness"? — So round and round you go, spinning mental wheels and nowhere finding anyplace to get traction. What the hell is Quality? What is it?

Gumption

I like the word gumption because it’s so homely and so forlorn that it looks out of style it looks as though it needs a friend and isn’t likely to reject anyone who comes along. It’s an old Scottish word, once used a lot by pioneers, but which, like "kin," seems to have all but dropped out of use. I like it also because it describes exactly what happens to someone who connects with Quality. He gets filled with gumption.

The Greeks called it enthousiasmos, the root of "enthusiasm." which means literally "filled with theos," or God, or Quality. See how that fits?

A person filled with gumption doesn’t sit around dissipating and stewing about things. He’s at the front of the train of his own awareness, watching to see what’s up the track and meeting it when it comes. That’s gumption.

Gumption Traps

But there’s another kind of detail that no shop manual goes into but that is common to all machines and can be given here. This is the detail of the Quality relationship, the gumption relationship, between the machine and the mechanic, which is just as intricate as the machine itself. Throughout the process of fixing the machine things always come up, low-quality things, from a dusted knuckle to an accidentally ruined "irreplaceable" assembly. These drain off gumption, destroy enthusiasm and leave you so discouraged you want to forget the whole business. I call these things "gumption traps."

The Types of traps

There are two main types of traps:

Externally-originated setbacks – the best example is managing to leave out a step in a complex series of instructions.  This will always be a required item that’s not in the critical-path, otherwise you wouldn’t be able to skip it.  My personal favorite in this regard is gaskets for mechanical work, very small cables and DIP switches in computer hardware, and overlooking a version-critical sub-component in software.

Internally-originated “hang ups”.  I’m quoting Pirsig here, and I have to stop and think this one out every time I read it.  Example would be the inability to separate yourself (your ego) from your conception of both the problem and how you’re trying to solve it.  Oftentimes, when you’re hammering something together, you won’t and/or can’t ask, “Do I need a hammer?  Do I even need a tool?  Should this job even be done?”  This can also be the result of applying one problem’s “solution mindset” to another apparently similar problem.

The CygNet Motorcycle

The first [problem] is that a motorcycle, so described, is almost impossible to understand unless you already know how one works. The immediate surface impressions that are essential for primary understanding are gone. Only the underlying form is left.

Like airplanes, motorcycles tend to be composed only of the parts required to provide two functions:  acceleration (positive and negative) and operator affordances (seating and controls).  Everything else is strictly unnecessary.  As such, it’s next to impossible to build a causal model based on overall impressions.  There’s nothing a motorcycle is like except a motorcycle.

You need to understand it before you can understand it.  That’s the hardest part of CygNet for me,is  that it’s spent so many years being turned into a perfectly functional object that it’s not like anything except itself.  Since there’s a natural tendency, for me at least, to casually build narrative model shells around other people’s tools and then build a causal model, I’ve tried to do the same with CygNet and it’s been a constant struggle to undo this approach as soon as I subconsciously veer into it.

I’ve spent a couple years building, tearing down, and rebuilding my understanding of what CygNet is and how it functions.  I feel as though I understand it as well as anyone, although certainly not as deeply, and that’s where the gumption traps come in. 

Why is this important?

BECAUSE – IPv6 makes bunny cry

YouMakeBunnyCry

Instructions, tools, and products shouldn’t make people feel stupid, which I might carefully restate as, “It shouldn’t make thoughtful and smart customers with paid-up licenses feel stupid.”

Primary sources of my IPv6 gumption traps

  • It’s like IPv4, except when it’s not. 
  • They’ve obsoleted “standards”, e.g. 6TO4->ISATAP->RANGER (real soon now) on the fly.  Each of these is a way to tunnel v6 over v4.
  • Vendors are waiting for every other vendor to commit.
    Customer – “Does your device support IPv6?”
    Sales rep – “It depends…”
    C – “Depends on what?”
    SR – “What you mean by ‘supports’?”
    C – <facepalms>

    They’re serious.  At one level, Ethernet packets will get passed around by routers, but at another level, IP packets might get routed and might not.  If you’re using what appears to be a “flat” ethernet link, your packets will get where they’re going, regardless of IP version.  OTOH, IP packet routing these days on everything but carrier-grade equipment, means IPv4 stuff gets routed, which leaves you with the option of tunneling, using carrier-grade equipment, or using open-source stuff like DD-WRT and even there the support is tricky, marginal, and incorrectly documented.

  • ISPs are waiting for demand.  Customers are waiting for ISPs.  When they ask, and I have, we’re told, “No one wants it.”  As bad as that is, the reality is worse, because simply trying to find someone who knows what you’re asking about is difficult.  It might be different for corporate customers, but I doubt it, because my office uses business-class Time Warner, and while their sales staff and support droids are very helpful, even for obscure routing and IPv4 issues, IPv6 isn’t on their radar.
  • People in “developed” countries are in much less danger of IPv4 address space exhaustion than places like China and India, who seem to be driving a lot of the demand.  Training dollars for IT personnel have (in my experience) always been the lowest priority in any “normal” corporation, which means that networking personnel who say, “We need to go learn about a protocol that we don’t use and which isn’t fully baked in the market and whose benefits we’re incapable of describing in business terms,” are going to get laughed out of the budget meetings.  Result:  lots of us know a little, and the people who know a lot are either in hiding or categorically incapable of writing a declarative English sentence.
  • I think I understand IPv4.  That’s not a typo.  IPv4 is like IPv6 the way a bobcat is like a small tiger.  Superficially sleek and attractive, but not really user friendly, and subject to more-or-less random fits of violence.  With a bobcat, you’re hurt.  With a tiger, even a small one, you’re supper.
  • Documentation isn’t.  A lot of the so-called documentation is descriptions of standards.  Even with my subscription to Safari books, I’m finding it rough going.  There’s a crying need here for some books based on actual implementations, and that include lots and lots and LOTS of examples.

 

More on specific technical issues in my next post on this subject

 

 

You Should Never Make Normative Statements

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s