It's so much more than an abstract problem.
"Where it might frustrate a chess player, is that chess lacks an element of imperfect information."
Any chess player worth their salt deals with imperfect information, and has to manage risk, make kludges, pick imperfect paths, deal with the clock etc etc.
To quote Wikipedia: "In game theory, an extensive-form game has perfect information if each player, when making any decision, is perfectly informed of all the events that have previously occurred."
This is a technical designation, it has nothing to do with the future, only the past and current state.
Yes, to be a good chess player you need to be able to evaluate your opponent and make subjective determinations. Yes, your strategy is probably imperfect. But the fact remains that you can see the entirety of the game board and you can write down the history of moves, so you have perfect information.
In this context the fact that chess has perfect information in a technical sense is irrelevant, since chess as played is so much more than a game about digital information.
Change a few words, and it's pretty much a typical thought process when coding for me.
To airframeng: if you are interested in games with imperfect information, consider:
* bridge
* poker
* Twilight Struggle board game
These games hide competitor's positions and force you to reason about what your opponent's position could be, and not just what it is.
edit #2
Just thought of the perfect (pardon the pun) analogy. Chess has perfect information in the same way that a large code-base with 500k lines of code has perfect information. When I ask you how much time it will take to implement or refactor feature X, do you think you'll have enough time to read and learn the entire code-base before answering? How you approach that problem is almost exactly how you think through a position in chess.
edit #1
(tldr; chess teaches you to evaluate an overwhelming large number of options to evaulate and choose what you think is the best one in a reasonable amount of time, without having all the answers)
In all seriousness, the ability of human reasoning is finite and the skills that we apply to chess to deal with the seemingly infinite problem space apply very much to other things like programming. When we decide not to thinking deeply (e.g. multiple moves in) about a certain line of moves, it is because we do not deem them worthy of further thought, in the same way that I would, at an early stage, discard the option of refactoring an entire code base because, on the surface, the cost-benefit analysis is just too lousy. Also, in the same way that I can only think about 15-20 moves ahead at best along certain decision trees, I can only foresee and estimate so much of a software project before the limits of my knowledge and prediction power fail.
Chess is a game of perfect information where nothing is hidden from either side. Theoretically the white player should be able to win or force a draw every single game. It just doesn't happen that way in real life because to construct a tree of every possible move and counter move and then pick the optimal branch is hopelessly complex with this game. But for checkers it's doable (the best checkers players will play flawlessly and games are won or lost on a single mistake), and you probably already have tic-tac-toe figured out.
Edit: dang, ninja edit where you just said almost everything I said.
I think the honest way to think of this is that: Playing chess is a really good way of figuring out who is good at playing chess.
But, the abilities and aptitudes that often help aid being good at chess can be valuable assets in becoming a good programmer. Strong sense of logic. Able to think multiple steps in advance and the consequences. A strong memory can be useful.
Where it might frustrate a chess player, is that chess lacks an element of imperfect information. Real world programming isn't a perfect self-contained world where everything is known. It is impossible to know every aspect of programming as well as the rules of chess. You'll write bugs, and bugs in other software will create unpredictable problems. Users will add a random element into how your software breaks. Malicious attackers will find holes in what you've written. Things will just break.