With Deep Fritz's queen at E4 threatening to check mate at H7 with the very next move, Kramnik, instead of defending, blithely moved his queen from A7 to E3. In an instant, the game was over. Here is an account of the events:
Kramnik played the move 34...Qe3 calmly, stood up, picked up his cup and was about to leave the stage to go to his rest room. At least one audio commentator also noticed nothing, while Fritz operator Mathias Feist kept glancing from the board to the screen and back, hardly able to believe that he had input the correct move. Fritz was displaying mate in one, and when Mathias executed it on the board Kramnik briefly grasped his forehead, took a seat to sign the score sheet and left for the press conference, which he dutifully attended.
It's a fascinating thing. How could Kramnik have made such an error? There could be lots of explanations. He might have been ill or in a bad mood. He might have been experiencing a lot of stress because his opponent was a computer: It must be psychologically difficult to cope with the idea of an opponent with perfect memory who will never make a reading mistake or get tired; an opponent who can not be intimidated with an agressive move, or confused, or tricked. Never the less, the fact is that this mistake really did happen.
For me this might be an interesting example of a phenomenon I'll call the "expert's blunder," which can apply to anything, and in particular, to software development. A beginner in any field has a very small number of things he or she can keep track of. As one learns more and more about a given area however, one has to think of an ever expanding tree of concepts and ideas. Anything you do as an expert is heavier and more difficult. The more you know, the more tools are available to you, the more effort is required to choose which tool or approach to use next. It becomes easier to overlook something completely simple that a beginner would spot right away. As Kramnik was playing this ill-fated game, I think he wasn't really looking at the current state of the board, but rather at his own mental picture, a cloud of variations and possibilities. He might have got out of sync with his place in the actual game.
I've noticed this kind of thing happening to me when I've found myself implementing a more complicated piece of code than was necessary. Here's a case I blogged about some time ago for example: My original blog entry, followed by my realization that my code was over-designed. Here I too was getting ahead of myself, thinking of classes and subclasses and interfaces instead of just solving the problem in the most straightforward way. I think this kind of mistake is a good example of why TDD (test-driven development) and pair programming are useful tools in software development. The more we focus on the simple step-by-step design process of TDD and the more we constantly subject our code to critique as we do in pair programming, the less likely we are to develop bloated and over-designed code - however well-intentioned we might have been in writing it in the first place. I think this also promotes the idea of pairing a seasoned veteran with a recent grad: The value flows in both directions, not just from the expert to the novice. Not only beginners can write bad code. By virtue of their experience, people with more knowledge can be just as susceptible. At the very least, it's safe to say that one should always pause and just "look at the board" every so often.