Rigor or relevance: choose one

Back when I was a Mathematics undergraduate student at the University of Toronto, I was told by some of my peers that I was not a Mathematician but a problem solver. This was meant as a derogatory remark, but I thought it was a correct assessment. In short, I cared only about a given theorem if it allowed me to solve some interesting problems. I was not interested in Mathematics for its own sake. Rigor was not enough, I wanted relevance.

A given scientific or mathematical results has two properties: rigor and relevance. You usually can have one, or the other, but not both.

Engineers and technologists are good at determining relevance. They will discard quickly results that they do not need. The average software engineer is unable to prove that his program is correct. Even when rigor is important, such as when designing medical gear, the engineer is often not interested in proving the optimality of the techniques being used. By sacrificing some rigor, the engineer is able to innovate: if he had to prove every detail, he could never get work done.

Scientists make a business out of correctness. To ensure rigor and depth simultaneously, scientists stay close to the shore. Most scientists specialize in a narrow niche and take months to study what might be considered to be a minor point. This same minor point will get revisited by others. Their work tend to be very incremental. However, scientists are bad at being critical of the revelance of their own work. Indeed, if they did question their work too often, they may need to change topic too often which would reduce considerably their productivity. This explains why we end up with fields such as String theory or classical AI. Notice that you cannot measure relevance by the number citations from people in your field. In fact, the relevance of one’s research is usually never formally measured.

You would think that being critical would be a good thing in science, no? Alas, no. As an experiment, try to go to the next conference in your field and ask your peers whether what you are doing is relevant. It is a good recipe to become unpopular.


Aubrey D.N.J. de Grey, Curiosity Is Addictive, and This Is Not an Entirely Good Thing, Rejuvenation Research. February 1, 2008, 11(1): 1-3.

Dijkstra’s second rule for successful scientific research: “We all like our work to be socially relevant and scientifically sound. If we can find a topic satisfying both desires, we are lucky; if the two targets are in conflict with each other, let the requirement of scientific soundness prevail.”

2 thoughts on “Rigor or relevance: choose one”

  1. In AI both the “scruffy” and the “neats” failed.
    May be there is something else to care for, that would explain the poor progress in the field.
    It may also mean that neither the likes of Marcus Hutter nor the robotics tinkerers will “crack AI”.
    What could be missing?

  2. A scientist or mathematician may achieve relevance as a side-effect of aiming for rigour. It was once pointed out to me that many of the most cited results in math are lemmas, rather than theorems. (For non-mathematicians in the audience, a lemma is a kind of mini-theorem that is proven as a step along the road to the main theorem.) Some of the things that engineers do are “superstitions”, which are later shaved off by rigorous science. For example, the first refrigerators encased the cooling coils in a saltwater solution, in superstitious imitation of ice boxes, the preceding technology for cooling food. My point is that we need to alternate back and forth between rigour and relevance. First make it work (relevance), then clean it up (rigour).

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax