Glacial Erratics

Someday I'll rewrite this so it makes more sense.    (PRC)

Summary    (PRD)

If you lose track in the ramble below, here's the summary: Architect your hardware, your software and your life so your environment helps you out and you don't have to waste your brain deciding on things that shouldn't need deciding.    (PRE)

The Meat    (PRF)

In a conversation (in IRC, I haven't met Ryan yet but will next week) yesterday with my coworker Ryan, I was trying to convince him of the value of a service oriented architecture in systems design. While not entirely resistant to the notion, Ryan felt perhaps I was trying to impose needless boundaries that didn't provide any gain. So I tried a metaphor I've used before:    (PRG)

My earlier uses of the fridge metaphor described hardware systems, not software systems. In the physical world the metaphor mapped nicely, but it seems to map just as well in the abstract world of software and maybe getting things done as well.    (PRR)

If you have the fortune to live in the modern developed world you probably have a fridge and you probably rarely think about it. When you go to the kitchen you have a goal that's not directly related to the fridge. You're hungry or thirsty and want to change that situation. In the kitchen (the context of your experience) there is a suite of tools and appliances to help you achieve your goal. Tools like knives and forks augment you by extending your existing capabilities. Appliances like fridges automate certain process you either cannot or do not want to do. Elegant tools and appliances, like knives and fridges, do a small number of things (cut food, chill food) and present a small number of clear handles or activities for doing those things.    (PRS)

My earliest experience with a fridge metaphor was as a system administrator at Kiva Networking. We had the time and resources to create a collection of systems, each performing just one service, taking a small number of inputs and providing a small number of outputs. We put them on the network and if we were lucky, forgot about them while they serviced several thousand users.    (PRT)

We didn't call them fridges then. That happened with the re-architecting of the presentation side of Indiana University's Knowledge Base. A small army of cheap replaceable Debian boxes provides just one service: the front end to the KB. Boxes can be automatically installed and added and removed from the network.    (PRU)

Small cheap front ends to data services is nothing new and the reasoning for it is pretty solid and well accepted. It's harder to convince people that we should use the same logic for building software and maybe managing our lives.    (PRV)

In the software realm people develop a resistance to a fridge or service oriented mentality because some people have made those notions synonymous with the wordy, dogmatic, heavy-seeming worlds of multi-tiered Java and the mess of the WS-* standards.    (PRW)

It doesn't have to be like that. You can be service oriented by having and using components that present narrow interfaces, provide simple and predictable outputs, are easily layered, and (ideally) are location independent. That's it. Nothing's being said here about SOAP, or REST, or J2EEE. Perhaps we perceive those things as noise because they are insufficiently mature? Imagine the noise if a detailed knowledge of how a computer worked at the electronic level was a requirement for use?    (PRX)

What matters is the analysis that lets the designer or developer decide the points that are the boundaries between or chunks of automatable activity in the system. That is, which parts of the system can be described by theory given known inputs and require no additional inputs. For example, a wikitext to html formatter can be an independent automatic system given inputs of wikitext and perhaps a list of existing pages in the wiki system. We can reliably predict the output of the formatter, knowing the input.    (PRY)

We cannot, however, know the input, so gathering input is a process that is augmented by presenting an interface to the outside (to the user through some system). We may know, given a certain set of circumstances which interface to present, but we don't know what the user will type.    (PRZ)

A wiki formatter is a service we might wish to reuse or layer. Because we can know what it will take in and what it will put out, we can layer and reuse it in a relatively straightforward fashion.    (PS0)

We can make it a fridge. Once that is done, it is possible to stop worrying about it, and move on to the harder and/or less predictable aspects of the system where being smart is required. Places like making an effective user interface or innovating a new exciting feature.    (PS1)

Until the things that ought to be fridges are turned into fridges, they occupy an overly large segment of thinking in a developer's activity. There's a lack of foundation. Imagine how it would be if every time you wanted to eat you had to evaluate the fridge to make sure it is working correctly. All day long you would sit at work wondering, "Has the milk gone off? What am I going to do about dinner."    (PS2)

Properly made fridges remove fear and uncertainty.    (PS3)

Fridges do create boundaries, but those are a form of constraint that act as a form of external cognitive aid. The boundary lets you know what you don't have to think about: it keeps you in a limited space, focussing your thought on what matters in the current context. The boundary also lets you know what you can think about (related to the fridge): the boundary encapsulates a known and predictable space. You are not removed from your context: the fridge is contained, but not you. Constraints help you think about the stuff you need to think about.    (PS4)

Spacing Out    (PS5)

Hardware and software design don't matter much and do not a manifesto make. What's going on in the background here is a recapitulation of Doug Engelbart's (and others') ideas about augmentation fed through a filter of Landauer's descriptions of the differences between automating and augmenting systems. Those ideas are generally used to describe technical systems, but are really a way of looking at life.    (PS6)

We waste a lot of time making decisions that don't really matter. A monk creates space for contemplation by automating away much of their life into a rigorous routine of daily sameness. Our liberty is experienced in the decisions we make that feel relevant.    (PS7)

So how do we, and should we, figure out how to identify and automate into a fridge like state those decisions and concerns that aren't particularly relevant so as to maximize the experience of being relevant? There's more to it than being like the monk, but there's something there: routinize those things for which you almost always choose the same thing. Sure there's a cost to such behavior, but why waste time in the existentially alienating experience (for me) of wasting time choosing between a host of nothingness.    (PS8)

Engelbart's goal, all along, has been to figure out ways to solve the complex and urgent problems that face the collective we. Automate (only) those processes which can be correctly automated, and augment (place tools at your hands to navigate the gaps between automated processes) the others, removing the irrelevant, so as to approach problem solving as effectively as possible.    (PS9)

Automating and augmenting must involve a constant process of review and re-composition of the pieces that make up the system: When some collection of variables has become, after rigorous investigation, deterministic, you may, at your option, turn the system into a fridge and remove it from your concern. But only if you know the inputs. Most of the time you don't.    (PSA)

At the individual level finding the meaningful life is a problem to solve. If I make some fridges, I might find some additional relevant space. Room to breathe and think and do what matters.    (PSB)

Apologies to those who can't stomach geeking out about software and hardware with geeking out about life or take too seriously taking everything too seriously. Everything everywhere is a metaphor and it's all analogies to be learned, compared and connected. We want to remove fear and uncertainty in life at least as much as we want to remove it in software development. We want to think effectively about all sorts of problems.    (PSC)