Oct
28
Written by:
StevenFeuersteinTW
Tuesday, October 28, 2008 9:23 AM
Part 2: The Game of Mastermind
Software development is one heck of a serious job. It turns out, however, that there are several games you can play to improve the quality of code you write. This is the second of two blog entries that introduce you to two of my favorite brain development and training games:
Set and Mastermind.
Play either (preferably both) of these games, and you will write better software.
[ Note that I do not include Solitaire in this list. Playing this game will definitely not help you become a better developer, but it will pass the time. ]
I even encourage you to play these games on company time, with management approval. It will be a good investment by your employer. Sound crazy? I have been told by a number of my students that their manager did, in fact, agree to do this, and everyone is happy with the results. I will come back to this point at the end of this blog.
So the game featured in this blog is Mastermind. Mastermind has been around for decades, usually played on a small plastic box filled with holes into which pegs of different colors are placed. You can find lots of electronic versions of Mastermind on the Internet. Here's the one I used in my blog:
So how does it work? You have to guess the colors of the pegs in each of the positions, with the smallest possible number of guesses. Each time you make a guess, Mastermind (the electronic version) tells you how close you are by providing clues (when playing with another human being, they provide the clues – and hopefully they don't make any mistakes).
There are two kinds of clues:
- You got the color and the position right. Usually this clue is indicated with a black peg.
- You got the color right, but the position is wrong. Usually this clue is indicated with a white peg.
When you get four black pegs, you have won that round.
The game is more or less difficult depending on:
- the number of positions
- the number of choices of colors (including or excluding blanks)
- whether or not you can repeat colors in the solution
You could, of course, simply guess each time, in which case you will be very lucky (and only lucky) to actually ever win. But the point of the game (at least, the way that I understood the point of the game) is to use logic to narrow down the choices that are valid based on the clues provided.
Let's walk through a game of Mastermind. In this version, we will not allow blanks nor repeated colors. Here's the starting point:
First try: it's luck and random selection. In other words, one guess is as good as any other (this first turn is the only time at which this statement is valid)....so I will simply choose the first four colors in the order shown in the game.
Then I press OK and Mastermind shows me how close I got. One white clue.
Not very close! So only one of these colors is in the solution. This is a good start, precisely because there is so little information. Once I figure out which of these colors is in the solution, I know that the other three are not.
What shall I do next? Pick the color that I will assume is in the solution, and move it to another location so that, theoretically, it could then result in a black clue.
I will make the smallest possible effort here, and move black over one. I will then use the next three colors on the second row:
Time to verify my second guess against my first clue. I have only color repeated from the first guess, and it is in a different position. OK, this could be right. Wish me luck....press OK..and:
Not bad at all! Now Mastermind is telling me that two of these four colors are in the solution and they are in the right place. One other color is also in the solution, but is in the wrong place.
Time to make another guess. Let's assume that red and black are the black clues and white is in the wrong place. We already know that green, brown and purples are not in the solution (if my assumption about black is correct), so what can I use for the fourth color? There is just one left: yellow.
Where should I put the yellow and white? I have already assumed that red and black are in the right positions. So that means that white would have to be in the fourth position (I don't have three black clues), and yellow in the third.
This is getting suspenseful! Press OK and....
Hmmm. I seem to have taken a step backwards. Instead of two black clues, I have just one. OK, it is time now to stop and take stock.
What can I now conclude about the solution, given these three sets of clues? Quite a lot, namely:
|
A fact
|
How do I know?
|
|
The white is in the third position or the blue is in the fourth.
|
I repeated red and black and lost a black clue. Therefore, one of the two on the right half must have been the source of the black clue.
|
|
Both black and red cannot be in the solution.
|
If black is in the solution, then green, brown and purple are not. If red is also in the solution, then only one of white and blue can be in it. If white is in it, then the fourth clue tells me that yellow cannot be in it. I have now exhausted all the colors and we do not have a fourth color. That's not possible. So it's either red or black, but not both.
|
|
White, blue and yellow must be in the solution.
|
The second guess has three clues, so three of the four must be in the solution, but only one of red and black can be, so the other two must be. The third guess also has three clues and again, this means that the two that are not red and black must be in the solution, so yellow must be in it.
|
Now I have enough information to make the smallest numbers of assumptions and produce a solution. If this works, we win. If it doesn't, I will get lots of additional data from which to work (that is, it will show me that an assumption was invalid, forcing me to re-evaluate and take a new path).
Let's keep going with black in the second position; I haven't yet encountered any reason to think it is not there. That accounts for the one black clue from the second turn. Let's now go with white in the third position. Blue must then be in the first position, and yellow in the fourth.
I then go back and make sure this last guess is consistent with all previous guesses and clues:
- Guess/clue 1: Only black is repeated from the first turn and it is in a different position, so guess 4 could be correct based on this clue.
- Guess/clue 2: The black and white colors are in the same position and the blue is in a different position, so guess 4 could be correct based on this clue.
- Guess/clue 3: The black is in the same position, but yellow and white are now in two different positions, and I added in a different color. Guess 4 could be correct based on this clue.
OK, I have verified that this guess could be correct. So how did I do? Press OK and....
I did it!
Now, that's very satisfying, but I must also stay humble. I was lucky enough to make the correct assumption about black in the very first turn. I could easily have decided to assume that green was the correct color, and then spent several turns making guesses before I discovered I was wrong.
Regardless, at each step of the way, I used deductive logic to extract all possible information from the clues, and use them to construct another guess that is consistent will previous clues.
So what does this have to do with software?
Isn't it enough fun all by itself?
Sure, but I did claim that playing this game would help you become a better developer. So I really should explain. Here goes....
I claim that playing Mastermind a lot and getting really good at it will help you debug your code more quickly and accurately.
Conversely, if you have trouble "mining" conclusions from clues in Mastermind, I believe that you would find it very difficult, perhaps even torturous to debug your (or anyone else's) code.
Why do I say this? Well, let's walk through how we build our code.
I am handed requirements. I write a first pass at the code to implement those requirements. I get my code to compile (wow!). Then (theoretically), it is time to test my code.
So I run my test, and I get "clues" – my test (hopefully a regression test that exercises my code for a variety of input scenarios) tells me the circumstances of failure (When I pass in "ABC", I get 1 – the right answer. When I pass in "123", I get NULL – the wrong answer).
I might also trace execution of my code, giving me lots of additional clues.
I then take all this information (forget about up to four conveniently colored clues – I will usually get many more pieces of feedback then that!), use it to guide my debugging session, and identify changes to the code that I believe will result in a correct program.
That's my next "guess." I then rerun my tests, get my next set of clues, and on I go.
Now, doesn't that sound just like the process of finding a solution to Mastermind, only way more complicated?
So if you have trouble playing Mastermind, I've got to conclude that you will more easily get lost in the tangle of code and clues you get when testing. And if you can play Mastermind very well (which means, by the way, that you can also rapidly get to a solution even when duplicate colors and blanks are allowed, greatly increasing the number of possible solutions and requiring more sophisticated strategies for solving the puzzle), I am certain you will find it that much easier to juggle larger amounts of test feedback and apply all of that productively to your code.
2 comment(s) so far...
Re: Play games to become a better developer!
Hey Steven, maybe you will like to solve this dice game with PL/SQL
http://projecteuler.net/index.php?section=problems&id=205
I hope it will challenge you a bit :)
Laurent
By laurentschneider on
Tuesday, October 28, 2008 2:34 PM
|
Re: Play games to become a better developer!
Thanks for the suggestion, Laurent. I must admit that, perhaps because I have so much software to write these days, I don't feel much attraction to solving such puzzles with my favorite language. It does, however, look like a challenge! Why don't you post the solution when you have one? :-)
By StevenFeuersteinTW on
Sunday, November 09, 2008 2:48 AM
|