01.11.10
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
09.03.08
Posted in Apple, Go, Journal, News, Software Development at 11:28 am by Pablosan
It’s been over a week since I submitted my iPhone Developer Program application, and I still don’t even have official word that Apple has received it. I’m doing my best to be proactive, but I haven’t found a lot that I can do to get answers. I’ve sent off a message via Apple’s “Contact Us” link, but I have very little confidence that anything will come of it.
I know that they aren’t hurting for applicants and I know I’m a very small fish in a very large ocean, but I have always chafed at external and unnecessary delays. I’m quite proud of the work I’ve accomplished and would like the chance to show it off to the world and see how I fare, even if it is a piddly little app.
I know I’m not the only one in this situation, but it is freakishly quiet out there… maybe I should take that as a sign, but for now, I intend to provide occasional updates on this issue here until it has been resolved.
In the meantime, I’ve got some ideas percolating on the game of Go and a new Erlang article or two to publish. Just be prepared for news bulletin interruptions to this blog as notable things occur on the iPhone Developer Program front.
Permalink
08.01.08
Posted in Agile, Go, Iterative Development, Software Development at 7:17 pm by Pablosan
Don your crash helmet and fasten your seatbelt: I’m about to attempt my first foray into computational complexity. Women who are pregnant, children, and those with weak constitutions may need to leave the room or, at the very least, avert their eyes. Here we go!
The game of Go, which I’ve recently picked up (I’m “Pablosan” on DragonGo, if any of you would like to hit me up for a game), is fascinating for many reasons. What really caught my attention, though, is that, in spite of decades of trying, no one has yet to create a computer program that can beat the top amateur-level players, let alone professionals. While the rules of Go are quite simple, the strategies of Go are vast. Go is the epitome of “Minutes to learn; a lifetime to master.” One could spend their entire life studying Go and still leave much of the game undiscovered.
That sounded like a good challenge to me. So I spent a little time researching Go “bots”, subscribed to a mailing list, etc. and quickly found myself nose-to-nose with Computational Complexity. Yikes! I ran across this website, which lists the game of Go as EXPTIME-complete, and that quickly introduced me to Descriptive Complexity – “a branch of finite model theory, a subfield of computation complexity theory and mathematical logic”; the codification of which is credited primarily to Neil Immerman, Ph.D, a graduate of Yale and Cornell, a professor at UMASS, and winner of the 1995 Gödel Prize in theoretical computer science. To put it plainly, I had chosen a problem that landed squarely in the “nearly impossible to solve” category, and ended up way out of my league! At this point, I realized that I was attempting to swallow the elephant whole.
I pride myself in my acute problem-solving ability, and my primary approach to solving difficult problems is to break them down into smaller problems (which is one of many reasons why I’m sold on TDD). And the game of Go already has this sort of built-in. Though a standard Go board is a 19×19 grid, it is quite common for beginners to play on a 9×9 grid. For those writing programs to play Go, 9×9 is currently a very popular grid size, and even 7×7 boards are used. Why? Because this greatly reduces the problem complexity. Even on just a 2×2 board, the number of possible game positions is 3^4 or 81 (3 states per position and 2*2 positions). On a 7×7 board the number is already astronomical at 2.39e+23. Attempting to calculate the number of positions for a full-size board on the iPhone’s scientific calculator… well, broke it… okay not really, but it did display “Error”.
So deciding that keeping my sanity was preferable to starting off in the deep weeds, and wanting to see what I could accomplish with my shiny, new iPhone SDK, I thought I’d set my sites just a tad lower… on Tic-Tac-Toe! No wait! There are actually similarities between the games. Really! Both are played on a grid, and both have a possible three states per position. In both games, the players alternate placing markers on the board. The primary difference that really complicates Go (other than the sheer size of the playing field) is that markers (stones) can be removed (captured). The main benefit to me of downscaling from Go to Tic-Tac-Toe is that the problem domain becomes very manageable. Once I finish modeling Tic-Tac-Toe, I will have taken one, tiny bite out of the elephant named “Go.” My next, tiny bite will be to model Go on a 2×2 board.
At this rate, I may have a Go bot ready to compete on 9×9 boards sometime after retirement, which is currently scheduled around my 90th birthday; sometime in the ’50′s.
Permalink
