Stardate 2011.12.1: Hasty Decisions

I recently stumbled upon the blog of GM Mark Bluvshtein. He's a relatively new Canadian grand master (I think) of chess who is terrifically pragmatic. It occurred to me that most good chess players *are* pragmatic, because you have to be: You have to know how to do the least amount of mental work but still get the most out of your moves - otherwise you can run out of steam midway through the game, or through the tournament. More importantly than conserving on energy, however, Mark seems to be hypercritical of his own play. This is another trait that I've noticed on the highest-level chess players, and is something I think we need in programming more.

In programming, I've noticed a lot of architect astronauts thinking that it's more important to define up-front an architecture which encompasses every aspect of the project, and that architecture must be strictly adhered to, no matter the consequences. If a lowly dev comes up with a reason why it won't work? Then they're wrong, just because they're not an architect!

You can see I have no fondness for these kinds of developers who think they know everything, and aren't afraid of pushing their ideas onto you. At the same time, I have problems with it myself. As such, I've taken my natural hypercritical chess (and general life) approach and begun applying it to my coding. I can't tell you just how important this has been to my personal development in chess, in life, and especially in my programming.

When I first started studying chess, back in 2002 or 2003, I was a pretty big nub. I mostly played blitz, of course, but even in my tournament games, despite the fact that I was not bad at all at the club level, I rarely reviewed them. While I'd do the occasional analysis after the game with the person I played against, more often I'd go play blitz games with the others who were done and just relax. Blitz games are incredibly relaxing, although they also make us develop bad thinking habits, such as assuming that the thing we're planning to do is not that bad, and we don't need to do too deep of an analysis because we need to get stuff done quickly.

This is terrible thinking. Just because we have to get something done quickly in programming, that doesn't mean we should not analyze it as deeply as we can. We need to be very critical of our own ideas so that we can weed out the moves that are shoddy, and only proceed when we have concrete, realistic goals. For architectures, this is perhaps the most important thing to have: If we do only a shallow analysis and define by fiat a series of "Shalls" and "Shall nots" without dogfooding, then the project is likely going to die an early death when the requirements start to change even a little bit. We have to create an atmosphere of questioning every decision when it comes to the architecture, because it's going to affect the *entire* project. If it is only shallowly analyzed, then it's way more likely that the project will fail, in my opinion.

Have you ever made any hasty decisions on a project that ended up hurting the overall quality of the project? Let me know in the comments!