Five Principles from Chess That Can Change Your Software Game
I was teaching a coworker how to play chess over lunch one day when I was struck by the similarities between chess and software. I began using software metaphors to explain the basics of chess, and it became apparent that it could work the other way, too. Chess and software share many core principles.
Pattern Power
Both chess and software rely heavily on pattern recognition. The greater your pattern repertoire, the greater your chance of success in either field.
Chess patterns take the form of openings, forks, pins, and skewers, as well as various checkmate patterns. Quickly identifying patterns in a game often means the difference between winning and losing.
In software there are myriad well-documented design patterns, such as model-view-controller and inversion of control, all reflecting the fundamental principles of good design. In fact, every chess and software pattern is built on some underlying principle, proven over time. Without these patterns, we can drown in beginners’ errors trying to “reinvent the wheel.”
Define Success
Checkmate! Capturing your opponent’s king is the goal of every chess game. Lose sight of this (like by trying to capture the most pieces), and you risk victory.
In software the risk is even greater due to the number of legitimate goals: Cool features. Rapid delivery. A flashy prototype. Without alignment on what defines success, teamwork erodes, conflict spreads, and morale craters. As in chess, your win is put at risk.
Little Things Matter
Chess has its flashy moves, such as forking the king and queen or the surprise back-row checkmate. What is often lost, especially on novices, are the quiet moves required to set up the flashy killer move. Valuing small things like positional advantage and king safety is essential to mastering chess.
Successful software is equally dependent on the small things, such as error checking, refactoring, unit testing, and code comments. These often unappreciated, quiet practices are the bread and butter of successful teams.
Learn from the Past
Chess players and developers alike are subject to repeating mistakes, and both groups can benefit from recording games and performing project postmortems.
For those dedicated to excellence, reviewing performance is an often-neglected tool to improve your craft. By understanding why a project—or game—was successful, you learn to replicate success rather than just mimic the moves.
Prepare for the Worst
I know a chess teacher who talks about “hope chess” (hoping your opponent doesn’t make a good move). But what if he does? What if he makes a surprise move? Destruction usually follows swiftly.
Much software is written with the same blind optimism and suffers the same ignominious fate. Software faces merciless, often random, and sometimes malicious opponents in users, either human or digital. Established practices like defensive coding, rigorous testing, and peer reviews can protect you from the unexpected. Otherwise, Murphy’s law will prevail: Anything that can go wrong, will.
The comparisons between these two great pursuits extend beyond these five principles. Hopefully you’ve been inspired to see other similarities, and both your chess and software games will be all the better.
