Thinking outside the box

  • What is the next letter in this sequence: A E I. And this sequence: A B G D? How about this one: B C D G J?
  • A boy and his mother are in a horrible car accident. They are rushed to the hospital, but on the way, the mother dies. When they arrive at the hospital, the nurse exclaims: “But that is my son!”. How can that be?
  • You’re in the basement of a house. There are three light switches. Upstairs, there are three light bulbs. The door on the top of the stairs will lock shut behind you when you leave the basement. How will you determine which switch goes to which light?

These sort of puzzles are often presented as an exercise in “thinking outside the box”. However, if I were to “think outside the box”, I’d drill a hole in the ceiling of the basement so I could see the light bulbs. Clearly, that isn’t the intended solution, and most people wouldn’t think it would be a fair solution, either. The trick is to identify what “requirements” are real, and what requirements are imagined by the puzzle-solver.

When solving software problems, same technique applies. For example, my client for a chat application requested a link to the help information in the status bar. This would require some layout changes that I considered a little risky. Now, if I had suggested that the users didn’t need the help information, I would really be thinking outside the box. Instead, we ended up enabling privileged users to send URLs in a normal chat conversation, which was a piece of cake to implement. This way, the privileged users could help others with finding the rules. I consider this thinking inside a bigger box.

This is why I don’t care about thinking outside the box. Instead, look for the bigger box.

PS: Finding the bigger box is often easier if you work together. I spend an embarrassing amount of time trying to figure out the Petals Around the Rose puzzle. But when I sat down with my wife (who didn’t know it, either), we solved it in about 15 minutes (yeah, yeah, yeah, she solved it in about 10 minutes and only smiled cleverly until I got it 5 minutes later).

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in Uncategorized. Bookmark the permalink.