The Monk and the Mountain

Let’s do a fun problem.

Consider the following problem stated by Rudolf Arnheim (I’ll give the full reference later):

One morning, exactly at 8 A.M., a monk began to climb a tall mountain. The narrow path, no more than a foot or two wide, spiraled around the mountain to a glittering temple at the summit. The monk ascended the path at varying rates of speed, stopping many times along the way to rest and to eat the dried fruit he carried with him. He reached the temple precisely at 8 P.M.After several days of fasting and meditation, he began his journey back along the same path, starting at 8A.M. and again walking at varying speeds with many pauses along the way. He reached the bottom at precisely 8 P.M.?

I assert that there is at least one spot along the path the monk occupied at precisely the same time of day on both trips.?

Is my assertion true? How do you decide?

We need all the different ways to think about this on the table, so if you think it is true, how did you decide, and likewise if you think it is false? Make your case as persuasively as you can, and feel empowered knowing that whatever the answer is, those that answer true are as valuable to this exercise as those who answer false.


Thank you to those who participated in the discussion — this is only viable with your input, and I am very grateful. Even with only three responses, you can see that the range of approaches taken is very interesting and useful.

When I first encountered this problem, it was, as I mentioned, in a book by Rudolf Arnheim  More leadingly, the book is Visual Thinking. So I expect that I was primed to pick up a pencil and model the problem. Indeed, my solution was much like Arnheim’s  (just more sketchily), shown below:

Arnhem's visual solution to the monk and hte mountain problem

Arnheim's visual solution to the monk and the mountain problem

What took me by surprise, was that even though we are the “visual architecting” folk, few pick up a pencil to model the problem, preferring to try to solve it with only the benefit of the mind’s eye.  And generally relatively few people in workshops of 12 to 16 very talented people come to a convinced affirmative within the time allotted. What is more, in workshop after workshop, there remained some who were not convinced of an affirmative answer even when I modeled it like this.

So we started doing a simulation along the lines of the thought experiment that Gene Hughson suggests in the comments, except that we would ask one of the participants to help us, and we designated a line across the room as ”the mountain path” and we’d have one of us be the monk going ”up” the mountain and the other being the monk coming down. We’d both start at “8am” and walk in opposite directions, one from the “bottom” (one end of the line) and one from the “top” (the other end). And no matter how fast or slow each of us went, of course there is a point where we bump into each other — when we superimpose the two days, we can see there is a point where we’d be at the same point in the path. Can you envision this in your imagination? Of course, since it is the same path, the entire distance of the path is traversed on both days. (Coming down by way of the same narrow path, we’re always at a point we were on when we went up, just, for the most part, at a different time of day.) The issue is only is there a spot that we’re at, at the same time of day? And if we start at the same time, the answer has to be yes.

Well, it is true on the assumption that what we mean by “same spot” is in the spirit of the problem, so we’re not asking if the monk would step in exactly and precisely the same place (i.e. on the same grains of sand) on both trips. That is, if we don’t complexify the problem. Now, if we are expecting Ruth to try to trip us up with not paying attention to the gtchas in the details, we’d be excused if we anticipated the ways this could go wrong. (Which obviously an architect should also do. In which case we simply need to assert our assumptions, so we state the problem in a way that we can move forward with assurance.)

Still, even with this simulation, some people aren’t convinced. And I love that, because therein lies the most important lesson. Right, we already have important lessons on the table:

  • interpret the problem statement in the spirit in which it is offered, otherwise we over constrain our stakeholders when they are presenting their request to us. This relates well to the gist of Stuart Boardman’s post on Words mentioned in the comments on the Visual Thinking post.
  • get our hands dirty. One way we can do that is by modeling it, as informally as will suffice. Turn it into something we can model visually, mathematically, with a thought experiment or a simulation. To do this, we have to do what we do when we model — we have to use abstractions and representations. We have to decide what is germane and what is unnecessary. Etc.
  • representational redescription: when we present our solution, it is useful to be able to present it different ways. Someone who doesn’t “see it” in one form, may when the information or solution is presented in a different form.

And still there will be some who just don’t see what we may well think is obvious in the light of the solutions presented.  They may come to see it as we present the solution different ways. But they may not. So even when we don’t have entrenched vested interests and other sources of resistance to change to contend with, just at the level of perception there are differences that we have to work with. To work with understanding and empathy, because we are, or could be, those people in the group who just aren’t seeing what other people in the group are seeing.

We need to get modeling and visualization back in the toolbox of our software and technology culture!

Visual Thinking

Here is another of my favorite Richard Feynman stories (and fitting to honor the memory of Feynman today, for it is 25 years since the day he died):

“When I was a kid growing up in Far Rockaway, I had a friend named Bernie Walker. We both had “labs” at home, and we would do various “experiments.” One time, we were discussing something — we must have been 11 or 12 at the time — and I said, “But thinking is nothing but talking to yourself inside.”

“Oh yeah?” Bernie said. “Do you know the crazy shape of the crankshaft in a car?”

“Yeah, what of it?”

“Good. Now tell me: how did you describe it when you were talking to yourself?”"

So I learned from Bernie that thoughts can be visual as well as verbal.

– Richard P. Feynman, It’s as Simple As One, Two, Three

That boy became this man

Feynman Diagrams

Image source: The photo of Feynman is from Gleick, J. Genius


If you are just joining us, you may like to read the earlier posts in this series, for they set the context for our discussions of architect mastery. In this post, we have turned the lens of our attention to visualization — in our mind’s eye, but also remembering “sometimes a pencil is the best eye” from the lessons in observation in the fish story (, as well as using visual models to help us reason, design and communicate.

The discussion in the comments raises many important points, and provides many useful pointers (thanks especially to Peter Bakker) to resources, that help us explore and understand the role of visual thinking and visualization in architecting.