A word about assumptions

This morning I was reading a chapter in Jerry Weinberg’s
Becoming a Technical Leader. On the chapter on innovation, he poses the following puzzle:

A man hires a worker to do seven days of work on the condition
that the worker will be paid at the end of each day.  The man  has
a seven-inch bar of gold, and the worker must be paid exactly one
inch of the gold bar each day. In paying the worker, the man
makes only two straight cuts in the bar. How did he do it?

Stop reading now if you want to try to solve this.

The story goes on to explain the solution. The man cuts his gold into three pieces of the following lengths: 1 inch, 2 inches, and 4 inches. Very clever, because the idea is that the worker can now “make change” when getting paid.

I thought for a minute about how clever this was but then dug deeper. Why didn’t I get it? This whole puzzle hinges on an assumption. An assumption that we can foist off an unusual set of requirements upon the “user” (the worker). The assumption is that the worker will retain his wages every day and have them available to make change. Therefore, the burden of making the employer pay with exact change is removed. Nice.

Now I why I didn’t think of this? Because it’s counter-intuitive of me to introduce unexpected (and possibly contract-breaking) conditions into a solution. But in a wave innovation, Mr Weinberg did. But we can’t blame him. He’s a programmer and this is the kind of stunt that programmers are wont to do.

But back to assumptions. The lesson learned is: every problem drags along a set of assumptions. Sometimes the assumptions are as simple as “the default conditions” that we take for granted. And every solution also brings along a set of assumptions. It’s always a prudent idea to keep an eye on the assumptions. You never know what they’re going to tell you about the problem and the problem solver.