The Brain Teaser: Full Solution

This is part 6. After the fold I show the complete solution for assembling The Brain Teaser.

The Brain Teaser: Assembly hint

This is part 5. After the fold I reveal one hint -- the blind spot that initially prevented me from assembling the puzzle given the manufacturer's solution.

The Brain Teaser: The manufacturer's solution

This is part 4. After the fold, I show the solution provided with the puzzle. If you also received the puzzle in its original packaging, you should already have this solution page.

Disassembling The Brain Teaser

This is part 3. After the fold, I show how to finish disassembling the puzzle.

Unlocking "The Brain Teaser" puzzle

This post is part 2 of several posts documenting the solution to the ECO Game Brain Teaser puzzle. For the benefit of anyone who only wants hints, in this post and the following most of the post will be 'after the fold'.

The ECO Game "Brain Teaser REMUE-MÉNINGES" wooden puzzle

Update: If you arrived here via a web search, you might want to see all posts about the puzzle. Click on this link to see the brief form of all six posts in reverse order, showing this post last and the final complete solution first. Don't worry if you are only looking for hints, the brief form of the posts don't reveal any solutions. I've written the posts such that you should be able to get only the hints you are looking for, when you are ready for them.

This is part 1 of six parts.

Santa left a fun wooden puzzle in my stocking this year. Whatever packaging the puzzle was in was recycled with all of the other packaging and wrapping paper that accumulated that morning. All I have now is the puzzle itself, and small slip of paper that has the solution to the puzzle. That slip of paper identifies the puzzle as The Brain Teaser / REMUE-MÉNINGES, with brand names ECO GAME and Relaxus. It provides the domain name www.relaxus.com, but I have searched that site and could not find any links to the puzzle. I conjecture that Relaxus is only the U.S. distributor and that the original manufacturer is French. If anybody reading this knows more details please leave a comment.

The puzzle looks like this:

Only one view of the puzzle is shown above but you should be able to get clear picture of the overall structure from the one view because of its many symmetries. There are three rectangular blocks with square cross sections that form a natural set of xyz axes. Rotate the puzzle 90 degrees about any of the three axes and you get the same shape.

This puzzle (like others in the genre) is two puzzles in one. First, you have to solve how to disassemble the puzzle. Then, you have to solve how to reassemble it. Disassembly is by no means trivial, but I was able to figure it out after a couple minutes. There is one trick to unlock the puzzle and then it almost falls apart. When I had figured out the trick, I impulsively decided to quickly disassemble the puzzle completely without making any attempt to understand the topology. My thought was that I wanted to tackle the second puzzle without 'cheating'. In the back of my mind I knew that if I got stuck, I could just use the solution page.

Later that day I sat down and spent about 20 minutes trying to solve the puzzle. It became clear that it wasn't going to be easy. I set it aside, and then spent another 20 minutes later in the evening, and then again the next day. I explained to my 5 year old daughter that for some problems I need to tackle them over several days and let my brain work on the problem while I sleep. By the morning of December 27th, I had 'slept on' the puzzle for a couple nights, but was still basically stuck. I debated with myself whether to give it another couple days, but decided to give in and take a peek at the solution page.

It turned out the solution page was pretty skimpy. I spent a few minutes trying to follow the instructions only to find myself reaching a dead end where the instructions seemed to be wrong. It took me another 10-15 minutes of head-scratching to figure out what was missing from the instructions that allowed me to go astray. During that time I did a quick web search and didn't find any links to hints or solutions. Since I have a little spare time this week I decided document the solution. I will attempt to structure this documentation so that anyone who is just looking for hints can get them without being exposed to the complete solution. After the fold for this post I'll provide one hint for anyone who hasn't figured out how to disassemble the puzzle.

Code Smells

My favorite tumblelog trivium (which is where I saw the links to the commentary on Shu Ha Ri that inspired this blog) just posted a link to Private Methods are a Code Smell, where Kent Spillner proclaims:

Private methods are a code smell. They should be moved to collaborating classes and made public.

His reasoning is interesting and concise and I highly recommend it. However, I also disagree, and think it is worth a post to explain why.

First, let's look at one independent definition of what  a code smell is. The Wikipedia entry says:

In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem.

Given this exact definition, I have to say that Kent is correct. However, it is because the word possibly in the definition leaves a rather large loophole. Yes, there are times when private methods should be refactored as Kent states, extracting them as public methods of collaborating classes. But I read Kent's post as taking a stronger stance. It is as if he almost titled his post Private Methods Considered Harmful. Of course, I may be mistaking his intentions, but let me pursue this anyway.

Recall the three phases of acquiring mastery: Shu Ha Ri. In the Shu phase, a beginning programmer must try to strictly adhere to solid foundational principles or rules. In the Ha phase, the programmer explores the boundaries of the rules, and learns when it is justifiable to break the rules. In the Ri phase, the programmer becomes free of rules, and simply does what is correct in the given situation.

There are many possible principles of programming. Beginning programmers should start with a small number of simple principles, such as: member data should always be private. This is an excellent principle for a Shu programmer to follow. A Ha programmer might experiment with occasions to violate the principle, but will probably learn through experience that every violation of the principle is a mistake.

Let's now consider another candidate principle: member functions should always be public. This candidate principle is close in spirit to Kent's proposed code smell, but Kent didn't state the code smell this way, and for good reason. This would be a bad principle to impose on a beginning programmer. Beginning programmers should follow principles that lead them to avoid repetition, develop an appreciation for encapsulation, and learn how to create narrow interfaces. But more importantly, beginning programmers should learn the principle to keep it simple.

But Kent didn't propose a fundamental principle. He proposed a code smell. So is it a good code smell? Consider the first five examples on the Wikipedia page I linked to earlier:

• Duplicate code: identical or very similar code exists in more than one location.
• Large method: a method, function, or procedure that has grown too large.
• Large class: a class that has grown too large, see God object.
• Feature envy: a class that uses methods of another class excessively.
• Inappropriate intimacy: a class that has dependencies on implementation details of another class.

These are all excellent code smells that are appropriate to teach to Shu level programmers. The private method code smell is another beast entirely. I can see how it might be a good code smell to give to Ha programmer, posing it as a learning exercise: Consider private methods as a code smell, and the recommendation to refactor them into public methods of collaborating classes. Is this a good universal rule? If not, what are the exceptions to the rule?

A Ha programmer who spent a few weeks with this exercise will very likely come out of the exercise as a better programmer. But if they conclude that the rule is a good universal one with very few exceptions, then I suspect they aren't yet nearing the Ri phase of programming. Your humble 4-dan programmer thinks private methods should only be considered a smell in the presence of other smells, i.e. the decision to refactor one class with private methods into two or more collaborating classes with public methods shouldn't be prompted by the presence of private methods alone.

Another of my posts might apply here: The Siren Call of Abstraction. In that post, I warn that programmers often fall into a kind of trap, where they are seeking a kind of purity through abstraction and generalization. The concept of code smells is a useful one, but I sometimes wonder if the art of programming doesn't also need a concept we might call purity smells.

One favorite principle of mine is: avoid speculative complexity. This principle deserves its own essay, but let me just say here that many programmers fall into a trap of speculating about future requirements of their applications, and attempt to design their applications so that those future requirements will be easy to implement when the time comes to do so. Programmers who have become enamored with refactoring might be inclined to do premature refactoring, which might be nearly as big as a mistake as doing premature performance optimization. I love refactoring as a tool, but for some time now, my refactoring has always been driven by the pragmatic concerns of doing what it takes to achieve my project's near term goals. With this style, there are a number of code smells that I find natural and intuitive, but calling private methods a smell seems a bit forced.