Rubber duck programming is awesome.

Oh, yes, that is a real thing. Don’t believe me, check it out for yourself.

I do have to admit, I don’t own a rubber duck. But, I do have a very effective method for not only debugging but also for solving general design questions as well. I call this revolutionary method the ‘Explain it to your Wife Test’. Don’t worry, a wife is not required! I just happen to be married to someone amazing 🙂 but you can also use the ‘Explain it to someone who is busy and has no context to what you are talking about Test’ instead.

So, the test breaks down into a very different phases.

Phase 1 – The light bulb

The very first phase is simple. All you have to do is be very excited about a solution to a problem you have been struggling with. Bonus points if you haven’t thought your solution though all the way. All you need is a general direction you feel like the solution should be in.

Phase 2 – The pitch

This is the fun part! You get to excitedly go to your selected person who is busy and has no context to the problem, interrupt whatever they are doing [because this is WAY more important] and start to explain how you are planning to solve the problem. They key here is not so much about what you are saying, but the facial expressions you are getting from your captive audience. If you manage to get all the way through the explanation and your audience is excited for you OR they are nodding their head, congratulations! You have just passed the test!

However, a situation the is more likely to happen is that your explanation will be interrupted. Now, I tend to follow the 3 strike rule of baseball in this situation. If my explanation generates more than 3 questions, it is out. No arguing, no talking about how it was the perfect idea, no pouting about how an awesome new feature would totally work if your audience just played more games like you [that one doesn’t go over well]. It’s done.

If, at ANY point, the face of your audience is contorted in a way that shows complete confusion as they try to decipher the gibberish you are spewing at them, the solution is out. No 3 strikes, this is an auto disqualification.

If you have to pull out your phone to show your audience a wikipedia page on physics formulas OR you ever say the word ‘thermo dynamics’, the solution is automatically eliminated and you are required to apologize to your audience.

Phase 3 – The sulk

You are here because your first test failed. That’s perfectly fine! Because now you get to go back to your computer and sulk about how that was the perfect solution and if you had to ‘dumb it down’ it wouldn’t really work because X,Y, and Z, and SURE, you could possibly do something to address issue X, but that would make it so issue Z was no longer there and then there is the issue with Y, but I guess that could be addressed by tweaking a small item and DAMMIT THEY WERE RIGHT! It’s solvable and you have already worked through the the deal breakers that you had before.

Congratulations, you have passed the test!

While this blog post is written in jest, this is a very valuable ‘tool’ to use for vetting not only programmatic issues that we run into but core system design problems or game mechanic proposals. We as programmers/designers/artists tend to over estimate our customers knowledge or passion about the things we are working on [sometimes we underestimate, but that is a different post!]. The issue with overestimating in this regard is we inadvertently leave minor context clues out in explanations or displayed stats or even tutorials and it leads to unexpected behavior for the end user. In the worst case, it makes the player feel dumb, and that will lead to a very bad player experience.

The key here is to not think of this as ‘dumbing down’ a system or a solution, but instead it’s about removing unintended complexity. Complexity != Fun, and in many cases complexity can turn fun into work.

So, go get those rubber ducks or ‘people that are busy and have no context to the problem’ and start creating!