emerging.org

I was just about to give up on this blogging thing - it’s really easy to put thoughts up, but much more difficult to do write anything with any lasting quality. It’s hard to remember that this medium is, for the most part, _intended_ to be junk.

Now, if something, anything, is intended to be junk, why bother investing time and effort? The result of effort may only be a temporary solution to a problem, like a hack to get code out the door, or scrap wood pulled into use as bracing. Similarly, there may not be value in a high quality solution for a particular problem. Consider most of the products people go to big box stores for.

I can understand this perspective - much of what we do daily does not require quality, regardless of what advertisers say. Focus on getting the best quality breakfast and you’re likely to have a hurried, low quality commute. You’ve got to pick your battles.

Where does this put blogging in daily life? Pretty far down the quality/priority chain, by most measurements. It tends to result in a low quality result, and requires an elective effort to get there. Maybe it’s _supposed_ to be some kind of transient art effort, a way to add an equal voice to the world, giving thoughts of the moment. It’s all logged, indexed, and archived, though, so it’s not very ephemeral. As for art, not a lot of blogs qualify on that front either. They’re mostly junk.

So why do blogs exist? It’s rare that a blog is directly solving a problem, temporarily or permanently. By their nature, they’re more _talk_ rather than _action_, which may be why they’re so popular. Since they don’t _do_ much, little is invested in their creation, which explains the general lack of quality.

By this chain of reasoning, blogs are low quality temporary (but yet permanent) inputs to solutions to problems in which they rarely take any active part in implementing. Hmm. Why am I here again?

On the other hand, aggrandizing is one act blogs can directly take part in, and they frequently do. This probably why they’re so tightly bound to the tech industry. They’re great at aggrandizing both people and products. (Ah, right. That’s why I’m here.)

To the point: I value quality, and this view I have puts blogging low on the value scale. To that end, I intended to give up on the idea again, likely revisiting it in another 8-10 years. (My previous effort in the late 90’s provided nearly the same value as the current attempt.) I just finished “Lila”, though, and had some thoughts I wanted to put forward as a last effort.

Some background - Lila, by Robert Pirsig, is a sequel to his “Zen and the Art of Motorcycle Maintenance”. It’s an expansion of his metaphysics of quality, which is an attempt to get to the roots of quality and value. The first was much better, in my opinion. Lila got further down the road of defining quality, but Zen took a much more interesting path.

Before I get into that, though, here are some Cliff notes. First, on Zen:

Pirsig is attempting to define quality, which is a hell of a difficult task. What makes one song better than another? How about a painting? An essay? Some people prefer high quality clothes to junk, or an iPod to a knockoff. What makes one better? Different people will give different answers, all according to their quality perspective. One person might like a BMW’s leather interior, another the engine characteristics, another the electronics. I see low quality due to the poor fuel efficiency. Sorry, but it proves the point - there is no specific quality metric.

The question here is not whether quality exists, but how does one define it? If it can be quantified, surely we can use this definition to be sure we ‘build quality in’ to what we do.

First, Pirsig finds a cleaving point that can divide quality into two camps - the classical and the romantic. Classical quality boils down to quantifiable categories and hierarchies - like engine parts, components, and subsystems. By looking at these categories, one can define the quality and value of a motorcycle based on the components that make the motorcycle work.

The other half, the romantic quality, has to do with the motorcycle as an ideal - the thought of the open road, wind in the hair, freedom. The intangible, and mostly socially inspired, aspects of the cycle fall under this half of the split.

As the book digs deeper into the roots of how we define quality, Pirsig goes all the way back to Plato, the roots of rhetoric, and the Sophists. He digresses into some interesting areas, but the end result is this:

Quality is not inherent in an object, or the observer. It is _created_ as part of the relationship between an object and the observer. This is why the definition can vary - based on our values and perceptions, each of us perceive quality in different ways. Each of us has a different relationship with the same object.

As he discusses classic(scientific)/romantic split he covers some interesting territory relating to the scientific method. How do we work through a problem? What rules do we use to decide what tools we use? What conscious methods decide our approach, and which are subconscious? The art of problem solving, Zen, and scientific method overlap in some powerful ways - he makes a convincing argument that the scientific method itself can only open up infinitely more possible solutions to problems, and Zen methods can help navigate these infinite possibilities to find and create quality.

The metaphor uses motorcycles, but could have just as easily used software. How do some developers nail the source of problems right off the bat, often without proper tools, or even data? It could be argued that they’re subconsciously using Zen and quality appraisals (gut feel) to come to the proper solution. Maybe a particular area of code is known to have little in the way of quality by some metric inherently understood, and the path to the root of the problem can be intuitively chosen from this.

This is partially why software varies so much in quality. Think about the fact that just to _debug_ it, many developers are searching for the root of a problem like traveling salesmen, trying to avoid local minima (low quality is the global maxima) using a metric (quality) that is arising dynamically between the subject (developer) and the object (code). Attempts to use the scientific method alone simply increase the space infinitely. Very few developers have the time or tools to effectively bisect a diverse system into problem and non-problem areas. Mathematically certifiable systems are a way out of this mess, but unfortunately, there’s more talk than action in this area. (Blogs, again)

On to Lila, before I get too distracted. At this point, Pirsig’s got a decent handle on the quality issue, but wants to dig a little deeper. So, the trip he takes us on isn’t as exciting, but he does get an important point across - he makes the distinction between static and dynamic quality. This is what I wanted to talk about.

Think of static quality as the patterns in life that are good. (high in quality, of course) It doesn’t matter what - it could be a holiday dinner, ’summers spent at the lake’, and so on. If it’s something settled in as a static pattern but with high quality, that’s static quality.

Dynamic quality is the new and exciting stuff that comes along. Pirsig’s got a perfect example of a great new song - the first time you hear it, it’s just fantastic. This is dynamic quality in action. It can come out of nowhere, and rarely follows a predictable pattern. As you hear the song played over and over through the next few months, it becomes less fantastic. Still a great song, but the edge (dynamic quality) is wearing off. This is the conversion from dynamic to static quality. After a few years, it’s just a part of static culture, and can be heard as part of the daily rotation on radios in motorcycle repair shops.

This distinction is really important, because it’s at the root of a lot of technology, at least in software. Static patterns are static because there are social norms around them; big, heavy weights that can be moved, but only over long periods with a lot of effort. Static patterns can be high or low quality , but whatever it is, it’s likely to stay that way for a while - we know where it is, we know where it came from, and to a large degree, it’s clear where it’s going.

Dynamic quality, on the other hand, is all over the map. It can come out of nowhere, on a whim; an idea drawn on the back of a napkin, an idea in the shower, etc. But we all know these ideas can vary greatly in quality, too - a brainstorming session gone awry is probably just as likely to produce complete garbage as it is a billion dollar idea.

Software tries to fall pretty squarely in this dynamic area. It’s so fluid that an idea can be pulled out of nowhere and thrown back almost on a whim, at least compared to trying out a new way to land a rover on Mars. This flexibility results in a large variance in quality. An astounding amount of bad software is written, but for all the bad stuff, some good does come out.

Software’s fun because it’s dynamic, and not bound by all of those static rules. And with the right idea, people, time, and effort, some really high quality work can be done, way out on the edge of the norm, away from all of those static patterns. You can call it the ‘Wild West’ or the ‘Next Big Thing’ or sometimes, maybe just a better way of doing what we already do.

The real fun part is that no one has any idea what in the hell they’re doing. The dynamic edge of quality is an emerging point, where there are no rules yet, no reference points, just a gut feeling about the right way to get done what needs to get done. You can come out with a great idea and execution, if you follow and create quality, down whatever seemingly random path the dynamic quality muse is travelling. If you lose the muse, or your gut’s read on quality isn’t quite right, you’re likely to go down in flames.

I’ve done dynamic development before. When you’re on the right quality trail, the work is just there for you. The right tasks are obvious, largely without surveys, market feedback, and so on. The high quality path is just taken. It may look like no one has any idea what they’re doing, but somehow it’s clear. There are no hard requirements, very few success measurement metrics, but yet the product does the right thing and customers love it. I consider this the high quality dynamic programming environment. (Some specific analysis tools were applied to our work later, and confirmed high quality levels, at least by the tool’s metrics.)

Open source development largely follows this model, with varying results in quality, just like there are other commercial development shops around that try to be dynamic but without the muse. There are some great projects out there, way out on the dynamic edge, and there’s some real trash. Amazing trash sometimes, really - looking at the minefield of what’s out there.

The OSS world isn’t just dynamic, though - some of it is very static. Many projects are just replicating existing software, like many of the core GNU packages - tar and the like. These projects can have high quality, or low, but of the static variety. In fact, most of the GNU utilities are (have?) far higher static quality (is quality a noun?) than what they’re modeling themselves after. There are a number of low quality static projects, but it’s easier to achieve higher quality when you’ve got something to compare to, like an existing cultural and technical static pattern.

This brings me to the other important point from Lila, the concept of latches. All of this quality is important: It’s important that static patterns (cultural (technical)) are of high quality, and it’s important that all this work around emerging dynamic quality is also good. But dynamic quality is, well, dynamic, and our static patterns are very static - it’s hard to change them. Without some way to fold this dynamic work back into the static world, it’s lost.

Here’s where the latches come in - Pirsig’s of the opinion that in order to make use of these new dynamic advantages, we need to have a latch where the static patterns are ‘upgraded’ to fold the advances back in. If this doesn’t happen, the culture doesn’t advance, and eventually stagnates and/or collapses on itself. Or some better culture comes along that has advanced and takes over.

An example latch would be the US Bill of Rights. That document took a number of high quality dynamic patterns and made them static. Without some serious effort, it’d be hard for us to fall back below this point. Sure, there might be efforts to regress, and anything is possible, but it’s not easy.

These latches don’t happen all the time - remember, static patterns don’t want to change! But it’s important that they’re out there, as a collection of new higher quality patterns, with the new lower quality patterns filtered out. When the static culture is ready for a change, it lurches forward, grabbing this latch, and internalizes it. The idea is that when this happens, these dynamic ideas _become_ static, like that new song I mentioned above. Culture can (and does) continue to progress from here, but if it starts to fail for some (environmental, technical, economical) reason, it only falls back to this latching point and not all the way back to the stone age.

I work on a lot of things, but I like to think at the core, this is what I’m doing - creating latches. We stay just ahead of that static edge, right where we can see the new dynamic and higher quality static patterns emerging. Through work and selection, we add to and collect the high quality work that’s out there, and turn it into a ‘latch’. In practical terms, a ‘latch’ for us is a software release. (And no, I’m not saying our Linux releases are equal in importance to the Bill of Rights.)

Once the release is out there, it can serve as a new cultural latch that is slowly internalized a number of ways. Over time, it becomes the static norm. At the same time, new dynamic work and advancements are continuing! Pretty soon, there are a lot of new high quality dynamic advancements out there, along with a solid smattering of improvements to static processes.

While the industry is internalizing the previous latch, we’ve been collecting and crafting these new advancements into a new and better one, letting the cycle begin all over again, improving all the time.

Dharma seems like most apt metaphor to wrap up with, but I’ll leave the process of thinking through the relationship there as an exercise for the reader. Have fun!