Programming and the chess game analogy

I find many similarities between programming and chess game. The incertitude and the ability to anticipate and respond to changes are common in both disciplines. It should inspire us to be very cautious about programming estimates. Only when we start a chess game or start writing code can we know exactly what we have to do. And we learn it step by step.

The main common elements in chess and programming are the following:

1/ Strict rules

Chess: very strict rules in pieces moves

Programming: very strict rules in the language syntax

2/ Study all options

Chess: before making a move, the players must study all possible options and choose the best one, considering the possible impact on his next moves, and the ones of his opponent.

Programming: before writing a function or even a simple condition, the programmer must have in mind the next steps, and be sure it won’t collide with other functions or conditions

3/ Bad options cause failure

Chess: a bad move or not optimal one can cause defeat. Even if it is not immediate.

Programming: a bad decision in a condition, statement or even a simple variable can cause several bugs. Even if we do not detect them straight away

4/ The goal

Chess: the only goal is to win. So the goal is to make the best sequence of moves to respond to the opponent’s moves.

Programming: a successful programming effort is the one where the program does what he is asked for, in any condition.

5/ We know after we start

Chess: it is only after the first opponent’s move that we can think about what we will have to do. Until the game begins, we don’t know what options we will have to take, and what problems we will face.

Programming: when we start programming, problems and difficulties appear. The real implementation work begins with the first line of code. Not before.

6/ Time constraint

Chess: each player has a given amount of time to make a move. He must concentrate, anticipate and react to the last move, but keeping in mind the countdown.

Programming: the same applies, but some project schedules and environments create a constant feeling of urgency, which will not help concentrating and finding the best programming options.

One difference

There is at least one main difference between chess game and programming: a programmer can modify some sequences of code that he has written before, refactor it, or even rewrite all the code. Which will imply additional time. In the chess game, once a move is done, it is done.


The conclusion that we can draw from the analogy between chess and programming is that trying to guess what the code will be, the options that will be taken when programming, and the difficulties that we will encounter, is not possible before we start writing code. It will depend on too many factors. And here I talk about the programming factors only.

But estimating is not just trying to guess how the program will have to be written. It is also taking into account the human factor: the programmer will have high and lows, the circumstances of life will impact his work, he will not have the same efficiency each day, or he will even find another job.

When a programmer estimates a task, he usually bases this estimate on a visualization of what the program should do. He cannot visualize how the program should be written (if not, he would have finished even before estimating).

So he cannot really estimate the time that it will take to write the program. He will rather figure out the rough size of the program and its complexity.

The result will be a rough estimate, not very accurate and that will not take into account a very important thing: the human factor and the incidents of life (and I do not talk about changes in the requirements).

Making an estimate is playing the match on the whiteboard, with an imaginary opponent (it cannot be compared to shadow-boxing, because the latter implies an action – only the opponent is an imaginary one – whereas estimates are produced before writing any single line of code). Writing code is playing the match for real. And with no margin for error.

One thought on “Programming and the chess game analogy

  1. 1. Strict rules.
    There are no strict rules when programming. The language syntax is a help, not some “limiting” rules. The rules in chess are there to create limits and boundaries (what if the pawns could move freely on the board?) That’s not the purpose of a programming language.

    2. Study all options

    3. Bad options
    Agree. In chess it’s the purpose of the game. In programming we have tests to help us.

    4. The goal
    Disagree. A successful programming effort is not the one where the program does what he is asked for. It’s about creating value. Whatever value is. A program that does what is asked for may still be the wrong thing to do – if it doesn’t create value.

    5. We know after we start
    Disagree, both in chess and programming. When starting a chess game you analyze your opponent and plan how to play – a strategy – long before the game begins (maybe you have even met him/her before). Same as in programming. The real implementation starts long before we start writing the first line of code. In chess, the one with the best planned strategy will win. And the one who has best alternatives when strategy needs to be adjusted will succeed. All those things comes with experience. Same as in programming. We must have a plan, a strategy, then we will succeed. And we must be able to adjust when it changes. And have margins for it.

    6. Time contstraint
    There are chess games with no time constraints. And when there are time constraints, they exists to create extra “tension”, to force wrong moves in the game. The same thing will happen with programming tasks under pressure. But in programming you can guard yourself from pressure by having margins or having an open communication with customer; customer collaboration.

    It’s a huge difference. The analogy isn’t even good. Chess is leisure/sport. Programming is business. If you have to rewrite code you should talk to customer first. Why do you need to rewrite? What’s the value in that? What’s the impact of doing that? How will it affect budget/time? Remember: customer collaboration.

    In chess we guess the outcome. “Who will win?” You can even bet on a winner. And there are odds. All estimates based on previous victories and other things.

    If you know what to build and how to build it it’s possible to estimate. And if you don’t know: start there, ask customer what to do. Customer collaboration. If you are unlucky, customer will turn to another supplier who knows how to build it and are willing to give/estimate a price/time (you will loose customer and soon are out of business). Or if you’re good at explaining why you don’t know roughly how long it will take, I bet your customer is willing to help you get to that knowledge. In collaboration you will agree on an approach both can accept.

    When I estimate I always vision what it should do *and* how it should be written. I think you do too, if you think about it.

    Trying to figure out the rough size and the complexity of the program is: estimating.

    The purpose of an estimate is not to be accurate, it’s to give customer a sense of cost and when to expect it to be done. It will certainly not cost exactly that and be ready exactly on that date. But customer will have a sense.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s