Assumptions
Ron Graham
with Tim Wescott
The role of assumptions is to simplify some problem; to shorten the time needed to reach some solution. We don't KNOW EVERYTHING. So we guess.

The best assumptions you already have high confidence are right, or will let you make progress while checking, or will be low cost if they turn out to be wrong. The worst assumptions are usually the ones that you make without thinking -- you've learned to use them so early and often that you've forgotten they are assumptions. They lead you into grand designs that don't work.

There are several ways a problem can be simplified:

  • Remove options that aren't realizable, whether because they cost too much, take too long, violate some physical law or strain some personal or political relationships.
  • Remove options that lead to maximum punishment if unfulfilled.
  • Remove options that lead to "zero-sum games" -- either we must do something a certain way or don't do it at all.

When you remove options, you create risks:

  • Will my answers be "close enough?" How can I know?
  • What level of uncertainty can I afford?
  • What are the consequences of any assumption that's wrong? Am I ignoring some phenomenon that can't be ignored?
  • Am I distancing myself from the real problem? Am I solving something completely different, just to save time or money?

We always have some of these questions in the backs of our minds -- and the degree to which we worry about them is proportional to how much we've simplified the problem. But here's how we form most of our assumptions:

  • History. Certain assumptions may have worked well in the past. If not for ourselves, then for others. Maybe we can find them in the literature. Or maybe we have learned them from someone else.
  • Feedback. Though we'll always be inclined to value some opinions over others, it's probably a good idea to run assumptions past anyone else working on the problem. Or anyone else you come in contact with who could be affected by the problem (or the solution you come up with). Feedback, especially from those with a point of view different from yours, is critical in problem-solving.
    • State your assumptions clearly whenever you talk to others, and allow them to be checked.
    • Listen carefully to any feedback you get. It may save you.
    • Thank people for their input. If they are right in pointing out some big fault that you've overlooked, thank them again. Better to be embarrassed in a small meeting than suffer a failure in the field.
    • Find simple tests that check the validity and boundaries of your assumptions. If an assumption could have expensive consequences, find a test even if it is expensive.
    • Perform product testing. Design complex tests to check assumptions, as you did earlier with simple tests. Pay attention to your results.
    • Keep an open mind. Be willing to be skeptical of your assumptions at a moments notice. If you suspect that an assumption isn't valid, find a way to check it.
  • Ranking of variables and constraints. If there's nothing at stake, why worry? So we rank the problems according to our perception of the risk associated with each.

Some types of common assumptions:

  • Linearity. Linear operating conditions are a risky assumption, because it's nonlinear behavior that tends to cause things to break. (Example: the Tacoma Narrows bridge was designed assuming its cables to always be under tension; but strong winds caused cables to cycle between tension and slack.)
  • Lumped Parameters. The capture of global phenomena through the ignorance of local (e.g. placement of sensors).
  • Approximations. Such as the small angle approximation or other uses of the Taylor series, or the Fourier series. The ignorance of relatively small numbers in favor of the relatively large.
  • No losses. Such as frictionless surfaces, or lossless wires or pipes, or seamless interfaces. The representation of "mysteries" by what's more easily and readily understood. (NOTE: nonlinearities are often ignored unless they can't be. But some fundamental designs depend on friction and/or loss!)
  • Describing functions. Such as the Pade approximation, or other versions of the Taylor series expansion. The grouping of "second-order effects" into a single first-order effect.
  • Planar representations. One axis matters less than the others.
  • Symmetry. What in the world do we do with an offset?
  • Smoothing or windowing. Reducing the impact of a finite amount of data. This is commonly seen in statistical experiment design.
  • Safety factors. Because we don't know everything.
  • Preventive maintenance. Because we know that we're forgetting something.
  • Predictable human behavior. It's risky to assume we understand human behavior, or that we can predict response sequences. This is often the most risky of assumptions. The first assumption to be tested in any system that's dependent on human responses or sequences of events.

So we like to take advantage of

  • symmetry
  • coordinate systems aligned with physical features
  • lumped parameters
  • first-order effects only
  • linearity (or tightly bounded nonlinearity)
  • finite time and knowledge
  • predictable event sequences
  • regular (or tightly bounded irregular) human behavior
  • necessary ingredients and tools at hand

And the Greatest Expected Problem, the Worst Thing That Could Happen, will generally involve the simultaneous failure of several of these assumptions to apply.

Documenting Assumptions

There's a tradeoff involved in documenting assumptions, between introducing them all at once and introducing them as you need them. If you introduce them as you need them, it's tougher for others to use the document as a reference.

If you introduce them all at once:

  • readers may forget them by the time they're in effect (so do we remind the readers?);
  • it's more likely for readers to see that legendary Step Two, "then a miracle occurs," whether it's there or not; and
  • it disrupts the flow of the document, especially at the beginning.

In either case, if readers don't get what's going on, the assumptions won't help anyway.

Ilana Stern, Allan Adler, and Joseph Chew contributed to this summary and may not even know it. :-)


[Table of Contents] [Previous] [Next]