01.11.10

Go and Software Development

Posted in Agile, Go, Software Development at 2:04 pm by Pablosan

I recently ran across Kent Beck’s blog post, Valuing Ambiquity. In it he uses the game of Go as an excellent analogy for dealing with ambiguity in software development.

I have been a casual Go player for about two years now, ever since being introduced to the game by a friend and former teammate. Around that same timeframe I read somewhere online that all software developers should learn the game of Go (sidenote: if there was ever a case for Semantic Web, it is Go. Googling “Go” is… pointless).

I’ve written about Go before, and looking back on my approach to Go so far (I am probably rated around 20 kyu, which is a rank beginner) gives me plenty of object lessons.

One such lesson is looking at the game as an emerging design. I have no idea what the end state of a game of Go will be. The way I currently approach the game is to quickly survey the entire board with a bias for the area in which my opponent just played, in order to narrow my focus to a few strategic moves. This usually leads me to a smaller section of the board, where I will play out a series of moves in my head to determine which of my possible moves seems the most valuable (value being defined as the right balance between potential gains and potential losses).

I have found the same approach useful in improving the design of legacy code. In dealing with very large codebases (over 500K lines of code), I find it impossible to determine what the end-result of design improvements should be. However, I can look at small parts of the system and see small ways in which the design could be improved. Many times I am looking in a certain section of code because a search for the root-cause of a defect has led me there (my opponent’s last move?). Writing Unit Tests allows me to explore the problem space and find the best course of action. All of this leads to incrementally improving design, which in turn increases value.

The hard part, both in the game of Go and in software development (as Kent Beck clearly articulates), is dealing with ambiguity. I cannot lose sight of the big picture: staying focused on a small subset of the overall problem space almost certainly results in failure. Yet allowing the insurmountable complexity of the big picture to paralyze me is as detrimental as losing sight of it.

Like so many things in life, it’s all about balance: balancing potential gains and potential losses as well as balancing focus on the big picture and focus on the details.

Permalink