Making the Right Moves

May 24, 2009 20:30
If you've ever played chess, you know how important openings are: castle early, protect your king, get some control... Time-proven, standard ways of starting a game, they lay a foundation for your victory.

It's similar in software development. Before you start a project, there's a lot of pretty standard things you should think of - from development process to architecture to testing and deployment.

These are your openings.

Requirements.

Requirements define the rules and the pieces you will play with. They specify whether you'd play conventional chess or have, say, an archbishop[1].  And while you don't need to have all requirements fixed in stone, it is important for the team to understand what needs to be built.

For that reason basic rules and pieces never change. After the game has started, you cannot ask knights to have bishops' abilities. You cannot request three rooks.

Architecture and design.

This is the time of the opening, time for long- and middle-term decisions. Those are your pawns that don't move backwards, as well as (possibly) your knight on C3 blocking the c-pawn.

 Here you decide whether to use ASP.NET MVC for UI, or employ Typemock Isolator as a mocking framework for unit tests, or take Entity Framework as ORM.  As in a chess game, you don't really experiment in the beginning. Instead of micro-thinking about squares and pieces, you think in terms of "attack vs defence" and "open vs close" and "quiet vs aggressive".

Definitely, the openings theory evolves and you need to keep tabs on that - but you build the basement using the knowledge already formalized by others. And then, kid gloves off, move into the middlegame.

Process.

If you made a wrong move, there's no takeback. Seriously. You may think it is possible to change anything, say, pick up a different development process after you've already established one, but it's not a takeback: it's something called vacating sacrifice and you start from scratch. You still can win, but you just have lost tempo.

Waterfall methodology looks like a "prefabricated" list of moves, concocted regardless of the other side's reactions. In a hardly predictable business of chess (the beginning position offers twenty possible moves), this will never work. Everything could change after a ply[2] of your opponent so you learn and adapt: the idea of an iteration is carried to its ultimate.

And here are more:
  • Retrospectives. You write down the moves so that you can analyze them later and catch up in the next game.
  • Time tracking. Having a deadline means you need to constantly monitor the time, making sure it's spent appropriately.
  • Tasks breakdown. You break efforts into smaller tasks and don't anlyze several paths of a game tree in one swoop.

Testing.

Chess metaphor also gives a notion of testing, although chess players don't use tests. (So this is the area where software development prevails the game.)

Every now and then someone finds a refutation to an opening, in the same way as people find bugs in software. Refutations reveal a blunder or find a loophole, and they get published so that chess players can use the counterattacks. But refutations are not unit tests. There's no way for a player to ensure a move is not flawed - only analysis and memory work here.

I've never been to world champion matches but read that prior world matches, e.g. between Karpov and Kasparov in  Moscow, there would be an audience of 3,000 people in a hall with the players on a stage, and you could not tell those Russian fans to keep quiet because they wanted to shout out  moves[3].  So a player, sort of, could get a quick response to the move - but that's too late.

Final thoughts.

 In software, we're lucky we can use testing. And we're probably even more lucky we can use the chess metaphor: it's clear and fits pretty well in some areas of development. If you think there are more parallels to be drawn, feel free to drop a comment or two!

If interested more in chess vocabulary, check out this Glossary of chess. 


Footnotes.
  1. Fairy pieces are not used in conventional chess but are mentioned in some cranky chess problems. 
  2. Ply is a term from game theory that refers to one turn taken by one of the players. Funny enough, it's a back-formation from the word "reply".
  3. Here's a hilarious (alas, incomplete) commentary on one of Kasparov vs Deep Blue games.

Tags:
Actions: E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed
Comments are closed