Framing and Questioning

As a mental exercise, two colleagues and I have been spending time uncovering and documenting the problem frames in internet email. It is nice to frame a complex, concrete example that has architecture descriptions readily available. We can compare what we come up with against the machinery that’s already been built. Initially, I didn’t want to know too much about how things really worked so I could stack up our frames against the architectural solutions that already exist. Lately I’ve discovered that by examining technical architecture descriptions, I can quickly frame new parts of the problem…which I can then use to loop back and try to understand the reasoning behind existing architecture.

Based on the problem we’re framing, we can also conveniently draw parallels between email and the physical world of postal mail. Today, Jim explained to Nathan the difference between local and internet based dispatching of mail by drawing an analogy to delivering mail within your house. If you address a letter to another family member, there’s no need to put it in mailbox, just hand deliver it. While the physical analog of postal mail is interesting, there’s a point where it is critical to drop it and focus on the problem at hand. Analogies only take you so far. But this got me thinking. How did the original architects of email find their inspiration? Did they create their solution based on perceptions of how the postal mail was handled? And if they did, when did they break away from that mental model and do the really heavy mental lifting needed to finish their design?

To me, an important aspect of framing is the questions it leads you to ask. Answering those questions helps you make design decisions. But even when looking at an existing technical design, framing has value. You can question why things are as they are and what problems were being solved. For example, in Qmail why are there two mail delivery strategies---one for local and one for non-local email? Presumably, because local messages can be processed faster and cheaper. Which leads to asking whether this is really necessary or a holdover from earlier computing days? Thinking for a bit, we enumerated a number of reasons why local mail can and should be handled differently than remote mail. (No need to check for spam, no need to go to a domain name service to get the host to transfer to, processing can continue when the parts of the internet are down…). In short, local email can be processed much more efficiently and outgoing mail should be processed much more reliably…they are two different concerns that shouldn’t be lumped together into the same solution. Problem frames can help you focus and subdivide a problem into smaller ones. I want to continue to wade deep into software machinery and critically examine whether framing helps me understand the nature of problems. I’m concluding it does. So far I’m not inventing anything, just exploring known territory. But even there I find value in framing and then asking why. Makes me feel like a two-year old, but then again, maybe not…analogies only go so far.