One More Level Of Indirection

It is said that there is no problem in computer science which cannot be solved by one more level of indirection (this sounds like a quote, has anybody references?).

The quote is credited to David Wheeler: [[please fix the URL -- how does one encode parens?)

But it also can add complexity to the system, and therefore is not a free lunch.

Definition of 'indirection' for the purpose of this page:

Proposed: Indirection is the ability to reference something using a name, reference, or container instead of the value itself. (from WikiPedia)

Proposed: Indirection refers to dispatch of communications via an intermediary. The intermediary is the cause of indirection, and is (strictly) an entity capable of examining a message and making a decision regarding it (e.g. to forward it or answer it, or on where to forward it, etc.). Because there may be more than one such intermediary, each intermediary along a communications path constitutes one level of indirection. Levels of indirection may vary on a per interaction basis.

And indeed if you think about it all problems can be made to fit this pattern:

I think you need to take some care to ensure that these actually qualify as 'indirection'. If you interpret the meaning too loosely, of course every pattern will fit. But it will also be weakened to the point its value is questionable (a bit like saying that all problems in computer science are solved by reconfiguring hardware and software). 'Indirection' as used in the typical context of the phrase above refers primarily to runtime dispatch of communications via an intermediary. As such, while most of your above examples work, the 'relation between customer and address' does not. Further, most of your examples below do not (e.g. the modular componentization, use of moderator, reducing strength, parallelization), though caching is an indirection. But what about 'non-functional' aspects? I think this could even be generalized to science at large.

What do you think?

In trying to find who first made this quote, I found an interesting counter-quote, equally unattributed:

Any performance problem can be solved by removing a layer of indirection.

I found it here:


That's probably for the same reason of RidiculousSimplicityDemandsRidiculousResources vs. RidiculousSimplicityGivesRidiculousResources. It depends on the kind of indirection. An indirection that has an excessive span (too many callers/callees) causes bottlenecks while too little span (only one caller/calle) is simply overhead. The trick seems to be to have many average indirections (like in the memory hierarchy).

Or, according to Java and Ruby advocates.. any performance problem can be solved by buying more CPU's. Har Har Har


EditText of this page (last edited November 3, 2014) or FindPage with title or text search