Garry Kasparov translated into Java Development.

About 2 weeks ago, I finished the book “How life imitates chess” by Garry Kasparov. For those who don’t know him, here is his Wikipedia entry. Anyway, the books has absolutely nothing to do with Java Development. But when I was reading it, most things could be reflected back to good development practices. I’ll share what I’ve learned.

First off, a small apology. I’ve read the book in Dutch, and he uses terms that I can only translate so and so.

MTQ

MTQ stands for Material, Time and Quality. Every thing you do can be mapped into these 3 parts. The material you are making, the time it took for making it and the quality of the finished product. It’s important that there is a great dynamic between the three. If you change 1 of them, at least another one needs to compensate. The sum is constant. Think about it. If you are nearing a deadline and have a unit of work to do, you can do three things. First is to produce less, second is to take longer and last is finishing with less quality then you would deliver normally.

His most important point on this subject was that the relation between the three exists. Always. There is no such thing as work faster during a period of time. Working faster generally means less quality. Period.

I see MTQ as a measure of efficiency. A good senior developer will produce the same material as a junior developer, but in less time and better quality.

Translating this into best practices, is to realise deadlines are not flexible without taking into consideration of the MTQ theory. Quality is probably the most abstract term, which reflects into less bugs, more maintainable code and better documentation.

Strategy and Tactics

A strategy is a road-map with certain goals. Goals could be learning a technology, get promoted into a certain function, learn a new skill… The goals are generally a long time further into the future.

A tactic is a certain action you will take, that gets you closer to a certain goal. The tactic fits in your strategy.

Translating this into java development is setting milestones into your release plan. Milestones are important strategies, and taking the hardest part first (if possible) is generally a good starting point for choosing the milestones. See the milestones as your strategy, as where specific implementation details are your tactics. Examples of such tactics could be choosing the right technology, using frameworks, and so on.

Side-notes he made are following:

• Strategies that change a lot, aren’t strategies at all: Change can be important but requires are decisive reason and good reasoning.
• Asking why a lot, make good strategics from tacticians. Asking why to yourself forces you to think things through, see bigger pictures and learn more understanding.

Decision Making

Even as developer, we need to make choices every day. We have to determine which the best approach is to resolve a certain problem, which implementation would be best, how we can refactor something and so on. Not to mention higher level decision making, like overseeing development, finding wrong implementation before they become problematic.

To make our decision making efficient, we need to direct the process. Kasparov states that you need to learn to make decisions and give pointers on how you should. Let’s solve a simple problem: decide the best bugfix.
Start off by giving yourself some time to spin up some possible solutions, brainstorm in your mind to provide even the most idiot solution. Search for at least 3 alternatives, let the imagination thrive! Now, depending on the amount of alternatives you’ve found, pick the 2-3 most promising and examining them. Think steps ahead. Ask yourself following questions for each alternative:

• If I change my code like this, where will my behavior change in other code? And if I change other code that was affected, will these changes affect even more code? (See the steps ahead coming?).
• Is my proposed fix easy to maintain, will I need to document a lot?
• Can I do better? How?

After questioning yourself, pick the best choice. Now, this may seem to take long, but you will be awarded following:

• Receive confidence in your code. Writing code in confidence makes you a better programmer (and makes it more fun).
• Be able to see bugs BEFORE they are written. No explanation needed here, does it.
• Write cleaner, better and more maintainable code. Your code will be smart, just like you.

See habits and deal with them

This one is something I do a lot as well. Coders tend to have certain habits, good and bad. A habit I tend to have is to dive into code straight away (Bad Bad Bad…). Other habits could be forgetting to write tests, commenting code and forget to remove it, writing idiot comments or none at all, choosing dubious names and so on. The point is, we should self-evaluate and see these bad habits. Knowing yourself is being a better person.

Everyone has a bad habit, when identified you should deal with it. Force yourself to write tests, hang a big post-it on the screen to never forget it. Personally I’ve make myself write halve the code in my mind before actually starting to write.

One of my favourites was that I knew about 5 shortcuts in Eclipse until 6 months. Identified this as a bad habit, printed the cheat sheet and forced myself to use them. When I didn’t , I deleted my piece of code I had generated and did it again by the shortcut. 6 months later I know like 50 shortcuts in eclipse, which owns. The downside is now with Eclipse Europe, they changed some of them (alt+enter for one), which is frustrating…

Game Stages

• Opening Game: In opening games you use a repertoire to setup the board. Openings are predetermined setups of the board. You can reflect this to use what you know, when starting a new project. Or better yet: use what works. Don’t reinvent the wheel. There are a lot of common best practices to be used when starting up a new project.
• The middle game: Here is where developing matters. Building up the application up to the next release. Nice play where one should overcome possible dangers and problems. No predetermined path can be found, as every chess game is unique (and so is every application), one will have to deal with the problems as they arrive.
• The endgame: Here the amount creativity drops to a bare minimum. See this as the final days before a release. Only a very limited path to success is available. Here we need to focus on what needs to be done.

The advantage of the attacker.

Attacking problems before they are too big is better then to wait until a problem is blocking. Attackers are in advantage because less code is dependent on the problem, making the solution simpler.

Final thoughts

I do admit, this is a limited snapshot of the book. I’ve filtered the stuff out that actually could be mapped into java development. Some topics he wrote about were a big stretch to get into the Java world . Anyway, I’ve tried on the best parts and I hope you enjoyed it.

More about the book

Do I recommend this book? Yes! Although it’s not the best book I’ve read in it’s branch, it’s definitely worth reading. I enjoyed mapping my mind to his, seeing how stuff he encountered could and did reflect on me. In the end, I became a wiser person, something I strive for at the moment.

It changed my perspective on certain topic, I especially liked the part about the MTQ and the decision making progress. Also the end of the book, which deals less about chess and more about dealing with yourself, was an eye opener on a lot of topics.