Van Vleck's Comb

Tom Van Vleck

Discussions of development process improvement often veer from indictments of management to arguments about the relative merits of programming languages and indentation style. I use a scheme I call Van Vleck's Comb (why not, Occam had a razor) to break down such processes into

Model	Who does what, and what the process is
Policy	Constraints and goals to make the model work
Procedure	Step-by-step execution of the policies
Tool	Automation of particular steps

The Model is a concise high-level description of how a process works. It names and defines the parts of the process. It can often be expressed as a picture or piping diagram. One thing it provides is a common vocabulary for all parties.

Policies specify what we're trying to optimize, and what should and shouldn't happen. The model is implemented by one or more policies, which provide control mechanisms to make things happen the way the model says. If the model is a piping diagram, the policies say which way things should flow. There will probably be multiple policies, because most processes have multiple goals. It's interesting to speculate whether the policies should be non-overlapping in some sense (probably good) and whether every model element should be governed by at least one policy (probably not, though considering this question may help suppress unnecessary detail in the model).

Procedures are the cookbook prescriptions for activities that carry out the policies. For any interesting process, there will be dozens of procedures. (Documents describing which people have responsibility for certain roles, or the file names and locations of critical resources, are also procedures.) Procedures are updated as requirements change, rules change, projects change, details change. Information should be organized so that changing one fact doesn't require updating many procedures.

Tools automate the procedures, where automation makes sense.

Mixing procedure, policy, and model together leads to confusion about the real reason for a rule, or the best way to make an exception or cope with a new case. Separating them, and understanding how models justify policy, and policy justifies procedure, helps apply common sense and avoid bureaucracy.

There isn't a strict tree structure here. You can't pick out a procedure and say that it supports just one of the policies, or expect that procedures will each be mechanized by separate tools.

Often people try to improve a process by introducing a new tool, hoping that this will force the adoption of better policies or agreement on a model. It won't work: this is trying to steer the ship from the engine room.

As you analyze your process with this framework, don't try to force completion of one layer before starting the one below; you need practical examples in order to motivate high layer generalizations. And don't try to do the bottom layers first and put the other parts in later: that risks entering into debate on details before they are justified. At any time, then, you will be working on all of Model, Policy, Procedure, and Tool. In each successively clearer version of your plan, lower layer details will be justified by higher layer statements. There is a downward flow, but it is of explanatory power, not strict time order.

I've been able to use this comb structure on several different kinds of problems. Sometimes I have used a two-dimensional analysis, with the comb's categories as rows and another natural division of the problem area (such as time frame or responsible department) as columns. Such a grid separates questions of what should be done from how to do it, and may point out areas where more work is needed.

Analytic approach; creative approach

This is one example of an analytic approach, that is, an attack on a problem by rearranging the existing facts. A creative approach, on the other hand, adds some new thought to the process, or restates the whole problem. Both are necessary.