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.
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.