Software Development Lessons Learned from Go

The ancient board game Go is the most popular board game in the world, and yet few people in the United States have even heard of it. Go is a game of metaphors: it has been compared to a fine art, a martial art, war, a conversation, life itself. Whereas Chess is a game of capturing prisoners, Go is a game of securing territory.

At it's core the rules of Go are incredibly simple: Two players (Black and White) alternate in placing a single stone on a 19x19 grid. Touching stones of the same color form a unit, which can be captured if all of the unit's neighboring spaces in both the horizontal and vertical directions are occupied by opposing stones. Grid points which are completely surrounded by stones of a single color become territory for that player. The game ends when both players pass their turn (because further moves would be of no value). The winner is determined by adding the number of points of territory plus the number of prisoners taken for each player. You can check out the American Go Association's rules page for a more detailed discussion of the rules of go.

Despite its simple rules, Go is at least PSPACE-hard, and could be as hard as EXPSPACE-complete, and the best Go programs consistently fail to perform much better than an experienced beginner. Though interesting, the computational complexity of the game of Go is not the purpose of this entry. What struck me, somewhere between the comment "software projects are like many other things in the world, like many other things in the world." on a recent entry by Jeff Atwood, and a blip about "writing code as art" by Jeremy Allison, is that the game of Go, like many other things, has something to teach about software development.

A large focus of Go strategy is to build only as much as is necessary to surround territory efficiently. A good moyo (territorial framework) is strong because it remains flexible. Good local moves serve multiple purposes; they protect your weaknesses as they build strength. All of this is good advice for software developers.

Two Go proverbs seem especially apt:

• After the 10th Punch You Will See the Fist; After the 20th You Will Block It: The popular adage "Fool me once shame on you; Fool me twice shame on me" enforces a pretty quick turnaround time on learning from your mistakes. While this may be appropriate for giving the shady mechanic an upfront payment or pulling a quarter from behind someone's ear, in Go and in Software Development it often takes longer to see the results of our mistakes, and still longer than that to uncover their root causes. Only once we are able to identify the mistakes we make, can we understand why we make them. And only then can we successfully plan in advance and avoid them. (Related: Lose your first 50 games as quickly as possible)
• Learn Joseki, Then Forget Them: Joseki are a sequence of moves which are understood to be mutually beneficial to both players. Each Joseki (and variation) has a place and time when it is useful to play from memory start-to-finish. However, it's more important to learn the reason for each move called for by the Joseki than the move itself; blindly following the Joseki in every case can easily lead to trouble, or a missed opportunity for a big gain. The software developer shouldn't blindly apply Design Patterns or Optimization Techniques. There are times when it's appropriate to optimize, there are times when it's unnecessary. There are times when design patterns apply, but there are times when everything looks like a nail. Instead of copy-pasting template code, learn why the design patterns are useful, and apply the concepts that fit to the solution that most suits your problem.

Professional (9p) Japanese Go player Kajiwara Takeo said in 1986 that Go is science, art and game. Those chosen few may enter the Eternal Hall of Fame only, who combine the scientific precision, the artistic improvisation and the spiritual joy of the game in themselves. This is just as true of software development: With time and study both skills can be performed well, but both require a unique combination of logic creativity and sincere passion to perform beautifully.

Photo by Brian Jeffery Beggerly