Aaron Iba's Blog

In the game of Monorail, it is a more valuable to be skilled at fixing broken solutions than skilled at deducing correct solutions.

I made the iOS puzzle game Monorail.  I figured that I, the author of the game, with my degree in mathematics from MIT, and years of puzzle-solving experience, would be much better at solving my own puzzles than random users downloading my app would be.  Users surprised me with a new strategy superior to mine, and this experience has changed the way I write computer programs and think about the business of startups.

The object of Monorail puzzles is to complete a closed-circuit loop through all the stations (dots) by drawing rails.  The loop must pass through each station exactly once and close back on itself, like an actual monorail system might in a city.

My Strategy:  Careful-Logical-Deduction

My strategy for solving these puzzles was to reason carefully about every rail before putting it down.  The game was specifically designed to be amenable to this strategy: each puzzle has only one possible solution-path given the starting conditions, which makes it possible to deduce each rail placement until you have solved a puzzle.

For example, you can observe that in a solution path, each station connects to exactly two neighboring stations.  (One rail in, one rail out).  Thus, since a corner station has only two neighbors, you know that it must connect to those two.

I developed layers upon layers of elaborate methods to deduce what rails must be placed on the board.  I solved puzzles by using logical reasoning, placing rails one-by-one until I have completed the path.

Better Strategy: Iterate-and-Repair

When I shipped the game, I used Flurry to track a bunch of statistics about puzzle-completion time because I was worried the puzzles would be too difficult for average users.  After looking at the stats, however, I thought there was a mistake because some users were solving puzzles faster than I was!  Were they cheating?  Was there a bug in the code?  No, they had discovered a superior strategy.

I found some of the best monorail solvers and observed them.  They would:

• Start by guessing random paths and just drawing whatever comes to mind.
• Fix mistakes.
• Repeat.
• If things ever look hopelessly messed up, then press the CLEAR button and start over.

I call this the Iterate-and-Repair strategy.

It turns out to be easier and faster to iterate from an existing but wrong solution, than to deduce a correct solution from scratch.  Even if you have to occassionally press the “clear” button to start over.

This realization inspired me to be more headstrong when writing computer programs.  I now put more emphasis on iteration and refactoring from a reasonable starting point, rather than trying to figure out the best possible design ahead of time.  If the code gets totally screwed up, I press the metaphorical clear button and use what I’ve learned to devise a new and better starting point.

I even used Iterate-and-Repair to write this blog post!  “Good writing is rewriting.”

If this whole post is obvious to you, then congratulations, you are already an Iterate-and-Repair kind of problem-solver.  To me, this was kind of a revelation.  I started out as more of a Careful-Logical-Deduction kind of guy.  I think this was influenced by my undergraduate education in mathematics at MIT, where so much emphasis is placed on logical reasoning and certitude.  Indeed, I’ve observed that many of my MIT friends who play monorail tend toward Careful-Logical-Deduction.

Now I’m more of an Iterate-and-Repair kind of guy, and I think I’m a better puzzle-solver, better programmer, and a better startup founder for being so.