Do not touch that stone – Do not touch that IDE

What’s the relationship between the ancient game of GO and writing software code?

It is possible to draw various analogies between these two sophisticated, intellectual human activities, but I simply wanted to note down a simple connection that has jumped into my mind recently. It can be summarized as a Go proverb:

Do not touch that stone.

And it can also be summarized as a programming  motto:

Do not touch that IDE.

What is the meaning of those sayings, other than being Zen-like statements? How and why did I come up with them? What are the context, story and history behind them? And most importantly, can they help us to be better programmers at all?

Let me briefly tell about it: Many years ago, back when I was living in Istanbul, I had a friend whom we shared a lot of technical interests such as programming, Linux, system administration and, well, yes, the game of Go. Whenever we had the opportunity we would sit before a Go board and we would play, sometimes for hours. Being a higher level player, my friend would comment on my moves, errors, and try to teach me to have a better feel of the game and various positions (which was not easy for such an abstract game).

One of the things he constantly said to me was:

Do not touch that stone.

He was referring to the fact that I was picking a Go stone from the bowl and holding it in my hand while thinking about my next move. He would repeat again and again:

Holding that stone in your hand creates a temptation to get rid of it by placing it somewhere on the board. Anywhere. But any position on the board is not the best position, not your best move. Thinking is stressful, you feel under pressure, you want to continue and you make bad moves when you want to get rid of that stone, which you can, very easily actually. Do not touch that stone, simply analyze the board, think hard, decide, then pick a stone and make your move.

He had a point (which led to more points at the end of the game! ;-)).

But, what about programming?

Do not touch that IDE.

Especially if you are trying to solve a difficult problem or, for heaven’s sake, if you are changing some architectural things. Programming, when it is about problem solving, is difficult. Making the right move, coming up with a good solution is hard, but if you are at the keyboard, with your IDE running at full speed, giving you so many code completions to chose, such an easy access to documentation and tiny little code examples and snippets, it is very difficult to resist the temptation to pick something, anything, that seems more or less not-so-bad, after all, you can easily change it… later… and you can also debug it… later… when it is too late… but hey, you might be Agile, so, it can’t be that bad.

Or can it be?

Maybe it is really not that bad for you. Maybe you are not really trying to solve a difficult problem. Maybe you think IDE is the best environment to think about a problem. Except when it is not.

I remember one other thing from my Go matches with my friend: holding the stone in my hand, trying to quickly progress led quickly to the end of the game. The end game was generally not good news for me, and having myself painted to a corner was not a good feeling at all. If Go was more agile, maybe I’d say, “hey, let’s refactor that game, shall we?”

Shall we?

Starting a new game from scratch turned out to be the only solution, which, at the same time, meant admitting defeat and failure. One often realizes that pretending everything is going fine in a game of Go is much more difficult than trying to do the same thing in a software project.

Maybe, for some of use, for some of you out there who is trying to solve a problem by creating an application, it is better to refrain from the fuzzy feeling of productivity, that popular perception enabled by very sophisticated IDEs. Because, you know, they are not going anywhere and when you really thought out something and found a better move, they will be there, waiting for you, just like the Go board and stones do.

I hope next time you touch that keyboard and mouse, glancing at the smart alternatives generated by your IDE, remember one last fact: Yes, your tools are getting smarter and smarter, saving you a lot of trouble and providing you with many capabilities, just like Go programs that use very advanced machine learning and artificial intelligence techniques. Still, a good Go player always beats the machine. Maybe, just maybe, there’s something to be learned from sitting back in a relaxed manner, and thinking about problems and solutions without yielding to the temptation of having done something, anything. (Even if your programming language is like Ducati and you feel hugely empowered by its sheer flexibility and agility.)

***

Now that I have almost finished what I wanted to write, I want to note that today is 15th November, 2013, and I hope my friend and former Go partner has a very happy birthday.

UPDATE (1-Dec-2013): I’ve just finished reading an excellent piece by Phillip G. Armour, in the October 2013 edition of Communications of the ACM:  When Faster is Slower. Starting from a similar premise, Armour arrives at a similar conclusion. Nice to see that someone more experienced than me, having worked at very different projects, arrived at a similar conclusion.