Oliver Steele

Decisions involve tradeoffs. Time at work subtracts from time with your family; money saved for the future subtracts from goods and services now; many food choices trade off among taste, convenience, price, and nutrition.

Some tradeoffs in computer science are the cost to update versus the cost to search, and execution time versus memory consumption. Tradeoffs in software development include implementation time versus execution time, and compilation time versus object code quality. Tradeoff in project management include resource pool size versus communications overhead, and cost versus time versus quality. These tradeoffs are some of the tradeoffs, respectively, in such tasks as choosing a data structure, algorithm, or cache size; choosing a programming language, a compiler and compiler settings; and choosing a project team size and personnel.

Often the factors involved in a decision are more complicated that A versus B. More time at work makes me happier, and more time with my family makes me happier too, but the contributions are different and non-linear. To some extent, I can sidestep the tradeoff between work time and family time by sharing my work with my family and vice versa, but this has different effects on different aspects of work: I make better decisions when I talk over the less technical aspects of what I do, but I can only achieve the flow state necessary for sustained technical work when I’m working alone. Family collaboration facilitates decision making and inhibits flow state; effective decision making and flow state both facilitate work enjoyment, which facilitates happiness.

This is a degree of complexity that it’s hard to keep in your head, and keeping it in your head makes it hard reflect on it. (The more of your system bus you’re using to refresh volatile memory, the less is available for computation.) Hence the constraint diagram.

A constraint diagram represents the factors in a decision. Lines between nodes represent interactions between factors. Arrowheads represent facilitation (increasing A increases B), and circles represent inhibition (increasing A increases B).

(The terms and symbols are from neural mapping. Substitute “promotion” for “facilitation”, and this is also the language of gene expression.)

A tradeoff is a choice between two mutually inhibitory factors. If increasing A decreases B, and vice versa, then a decision about the settings of A and B involves trading off between them.

Let’s look at a classical project management tradeoff: the three-way tradeoff among cost, time, and quality. There are a couple of ways to look at this tradeoff. One is by listing “cost” and “time” as factors which facilitate to quality:

The advantage of getting this onto paper is that it makes it easier to unpack the factors. Time vs. cost vs. quality is a simplistic way of looking at this. The diagram below illustrates the way that time, cost, and quality interact. The project manager controls time directly, but not cost: cost is an emergent property of staffing. Borrowing from the language of statistics, time and staffing are independent factors (they’re under the decision maker’s control), and everything else is a dependent factor. Cost and quality are the goal factors: they’re what the decision maker is trying to optimize. I’ve indicated independent factors and goal factors typographically in this diagram and the ones that follow.

(This model, which is still very simplified, is of a non-capital-intensive project that’s managed to a date, such as a software project with a hard launch date. Building an airplane or writing incrementally deployed software would have different independent factors.)

To make the model more precise, we can zoom in on, and expand, the relation between effort and quality. Effort can be spent either on the feature set, or on the quality (usability, extensibility, low defect rate) of the substrates and of individual features. Both of these factors contribute to the overall product quality:

Returning to the example at the beginning of this posting, of the family-time vs. work-time tradeoff, the following diagram represents graphically the factors that I described in text above. Like the time-cost-quality diagram above, it’s still simplistic (my family is happier when they participate in my decisions, and this makes me happier too, and also increases the amount of time they’re willing to let me spend away from home, which increases the time I have to get into a flow state), but it’s already an order of magnitude more than the degree of complexity that I can comfortably hold in my head.

Over the next few weeks, I’d like to explore the use of constraint diagrams to represent some tradeoffs in software engineering, especially where these tradeoffs intersect my other interests: software development, productivity, and the use of abstractions and high-level languages.

Patrick Roberts has written a fascinating post on Responsive User Interfaces. It’s easy to make a specific application responsive, through careful coding and by limiting what the user can do. An architecture for doing this, with arbitrary functionality, is one of the holy grails of GUI frameworks. Patrick’s post is a step towards this.

Patrick defines responsive as “the UI never locks up and provides at least partial results ASAP, not that every operation is completed instantaneously”. His design uses a UI thread that runs performs fast operations, and pushes slow operations onto a queue. A background thread runs these operations in priority order.

In his second post, Patrick refines the queue to handle superseded job items. This is important in a UI, where, for example, scrolling a list item out of the visible region of the list makes it unnecessary to figure out how to display it. It requires some finesse, because a naive implementation never gets around to displaying any of the items that the user is scrolling through. (A lot of work went into solving this particular case in the Laszlo implementation of lists.)

Patrick’s queue is just a step towards the responsiveness grail, and not the grail itself, because it still requires hand-coding to decide whether to perform each action immediately or place it on the queue, and to factor long-lasting tasks into subtasks that can display incremental progress — although maybe MVC usually takes care of the latter?

This design reminds me of David Allen’s Getting Things Done system. GTD is summarized here (PDF) and here. 43 Folders is an excellent site about how to use the system.

GTD can be thought of as a really sophisticated priority queue, and a decision procedure for deciding what to execute immediately and what to place in the queue. Each item in the queue has metadata: whether it has multiple steps, whether it requires additional information, its priority, external deadlines, and the context that the item requires: people, place, time, and energy. (GTD includes other storage structures too, and uses very different terms. I’m playing up the queue, and assimilating it to my own system, in order to make my point here.) When time is available, an item is selected from the queue according to the match between the current context and the item context, and then according to relative properties such as item priorities and external deadlines. For instance, I do my busywork tasks late in the day or when I’m otherwise feeling not at my sharpest; there’s some tasks I only do when I’m in California or when I’ve got a coworker on the phone; and there’s some that I’m only willing to start when I know that I’ve got a few uninterrupted hours in front of me. Beyond that, I choose according to whether there’s an external commitment and then by how important they are.

Here’s the idea I’m toying with: Use a queue like the GTD queue, and items with metadata, to schedule actions an application framework. The idea of matching task context with current context brings together some of the context-dependent actions that a computer performs. For example, indexing is a lower-priority task, but one that doesn’t require the user and doesn’t require an available time commitment to be worth starting; this is like my busywork. Synching, checking mail, and sending queued messages require a network connection; this is like my being in California or on the phone with a coworker. I also like the idea of adding metadata to an action, and using this to schedule it. In the GUI frameworks that I’m familiar with, the only metadata associated with an action is how to undo it (and what to call it in the Undo menu item). If the metadata also includes some of the same kinds of information that tasks in a project plan included, such as resources, dependencies, deadlines, and time estimates, then a GTD-style decision procedure can be used to move actions between a GUI thread, a background thread, and a Roberts-style queue.

There’s an obvious connection to blackboard systems and to AI planners such as Soar here. In fact, we can take a leaf from AI to solve the problem of how to supersede tasks, as in the scrolling case. The idea is that tasks have supertasks, and cancelling a supertask cancels its subtasks. (This is like a goal tree in planning; a process thread or child process in an operating system; and a project milestone or a milestone task in project management.) In the scrolling case, the task of rendering a list item is a subtask of displaying the visible content of the list. Once the list has scrolled again, the extension of the visible content has changed, and any subtasks of the task of displaying the content of the old position should be cancelled. (A smart system would pool the tasks, so that it could restart them or leave them running if they’re also subtasks of a new task — in the scrolling case, if the new position includes the same list item.)

Although the Roberts queue and the GTD system are similar, they serve different purposes. The Roberts queue was designed to optimize responsiveness — the time between the user event that initiates the action, and the initial feedback that the action is proceding. The GTD system was designed to optimize productivity — the throughput of the system, and the portion of that throughput dedicated to important items. Responsiveness and productivity are duals. A responsive application is easier to use productively, because it reduces input stuttering and it allows for tighter OODA cycles. And a productive person has an easier time being responsive, because (1) their backlog is smaller, and (2) they can tell you what their backlog is, and whether the task of responding to you is in it.

Tucker asked me if there was a name for the phenomenon where someone you don’t know asks you to watch over their possessions. I’m asked to do this a few times a day, for anything from books to laptops, at the ERC. (At the yuppie establishments that I also frequent, I’m not asked at all.)

If you’re worried that a total stranger might steal your belongings, why is it safe to ask a total stranger to guard them? There are at least two reasons.

The first reason is the asymmetry between your criteria, and those of a potential thief. Let’s assume some people are thieves, but not all. (If there aren’t any thieves present, it doesn’t hurt to recruit a guard, but you didn’t need to.) The chance of the person you chose being a thief is less than 1, but the chance of a thief choosing you (or your unattended belongings) is almost 1 — that’s our definition of “thief”: someone who is willing to steal from you. The chance of your picking a thief is therefore less than the chance of a thief picking you.

The second reason is social, not mathematical. Once you’ve made eye contact with someone and asked them for a favor — as long as you’re not obnoxious — then even if you did choose a potential thief, they’re less likely to steal from you. (This isn’t true for sociopaths, but even most thieves aren’t sociopaths.) Another way to put this is that interaction isn’t passive: asking someone for help changes the number of potential thieves in the room.

These are some hard questions my kids asked me when they were very young, with answers below:

• Why are far away things small?
• Why is it easier to pull a stroller (along a driveway with large gravel) than to push it?
• Why can we breath air but not dirt?

The challenge in answering this kind of question is to create an answer that’s comprehensible to anyone capable of framing the question. So, for example, the answer to the first question doesn’t have to do with ratios and similar triangles: this is a fine computer graphics explanation for undegraduates, but is (to use a metaphor) the assembly language version of an answer that can be written in Java. (Or the Java version of an answer that can be written in Haskell

Sometimes the process of constructing an answer means porting an answer back from a mathematical formulation, to an implementation on top of common-sense physics; a process that must be similar to translating a work between languages.

Some attempts at answers:

Why are far away things small?
So that they’ll fit. You can see many more far away things than near things; their images have to be smaller so that they’ll all fit in your eye.

Why is it easier to pull a stroller than to push it (over a rough surface)?
Because there’s many ways away from you, but only one way towards. When the gravel turns the wheels ithe stroller tends to change direction, but if you’re pulling it, there’s only one way that matches up with force from your hands.

This is similar to the well-known reason that it’s harder to pull into a parking space than out of one: there’s fewer ways for the car to be out of the space than in it. This is a useful principle to remember when you’re deciding whether to back into a space now or back out of it: back out of it later, because the rest of the task is easier. (This doesn’t apply when you’ve got extra time when you park, but you’ll be leaving in a hurry.)

Why can we breath air but not dirt?
(A dead-end answer is that air has free oxygen. But even if dirt enough too, our lungs couldn’t extract it.)

Our lungs can squeeze out air but not dirt because air is a gas. When you press on a gas, it goes wherever there’s less of it. When you press on a solid, it goes in the direction you press it. This means that squeezing a gas from all sides, like our lungs do, moves it out. Squeezing dirt from all sides would just compact it.

I’ve been reading about Col John Boyd’s OODA Loop — Observe, Orient, Decide, and Act — and I realized that some of the thinking based on this theory articulates intuitive reasons I’d had for liking zero defect milestones. Strategies such as “shortening your loop” and “getting inside” the enemy’s loop are those that zero defect milestones facilitate. If “Act” is the process of shipping a release, keeping the software in a shippable state preserves the ability of an organization to change the length of its loop based solely on external schedule requirements, without added constraints due to the accumulation of quality and other technical debts.

It’s notable how often MBA types use military analogies to justify business processes. I used to think this was to play up the glamour of business competition. Having learned something about the military from books such as Cognition in the Wild , it’s apparent that there’s another reason too. It’s not because business is war, but because war is business. The armed forces are the largest test field for the study of management, administration, and the creation and maintenance of institutional knowledge. Many of the processes for performing these tasks are independent of the line work that is being managed.

I’ve noticed that there’s two ways of giving directions to a location (say, when a driver pulls over to ask you how to get to a restaurant). Declarative directions specify where a location is relative to the current location; for example, “Two blocks ahead and across the street.” Procedural directions specify the steps that have to be taken to reach a location; for example, “Go straight three blocks, take a u-turn, go one block, and it’s the first building on your right.”
Continue reading…