The Global Day of Code Retreat - Mumbai on Saturday, 8th Dec, 2012. Agile India Global day of Code Retreat. The event was organized by ASCI and facilitated by Dhaval Dalal (@softwareartisan).
This was truly global event where 3200 developers from entire world met at 150 different locations for the entire day making this event successful.
The agenda for the entire day was simple. We divide entire day in multiple 45 minutes coding sessions. We have been given a problem (Snakes And Ladders) in the form of set of "problem statements" and we need to develop the same. This looks simple enough right ? The answer is NO. We need to develop the code using Test Driven Development (TDD) and with pair (Pair programming).
In Pair programming, two persons tries to solve the given problem together. One person is coding the solution(called driver) and another person (called navigator) is constantly monitoring him and the code he is writing. This would become interesting because there are two minds approaching to solve single problem. There are many cases where you make obvious mistakes whether its syntactical or logical. You only come to know them once you compile and actually run the code. The navigator always thinks about the code simultaneously with driver so possibility of bugs reduces a lot.
After 45 minutes there would be a timer bell which will ring. Every pair has to get up at that time and come to a close circle for analyzing what they have done in last 45 minutes.
1) Explain their design approach and they started from which problem statement ?
2) What they did really good ?
3) What they think they should improve on ?
Different pair can start solving the problem with different problem statement. The goal at the end of 45 minutes is not to complete the problem but to analyze what they have achieved in that time and how to improve their skills.
Interesting thing for every new session is that after every 45 minutes you have to DELETE your code. Yes you are not allowed to keep continuing from any of the part you have designed in earlier session. Also you have to switch the pairs. You will start again afresh with a new pair. And guess what, every new time you will be treated with a new set of constraints which you have to keep in mind while coding.
Some of the constraints are as follows:
This made us realize that how much our code "Sucks" and how much we still have to improve on. If we start applying various constraints like this to our actual code, the output would be fully tested code which is of very high quality. We never over-engineer anything unless its needed. In our design we never created "Board" class which would have been the very first class which will come to our mind while designing the game.
Also at the end we discussed practical usage of TDD. Most of us are working on so called "Legacy code" and only very few will have luxury to start a project from scratch. How do we use the TDD to our advantage on this kind of scenario. In most cases we should start with functional tests and behavioral tests of our code and then later to go deeper to have unit tests like this.
We had lot of fun during the entire day.. I am sure that everybody who attended this sessions worldwide would have enjoyed it.

The agenda for the entire day was simple. We divide entire day in multiple 45 minutes coding sessions. We have been given a problem (Snakes And Ladders) in the form of set of "problem statements" and we need to develop the same. This looks simple enough right ? The answer is NO. We need to develop the code using Test Driven Development (TDD) and with pair (Pair programming).
In Pair programming, two persons tries to solve the given problem together. One person is coding the solution(called driver) and another person (called navigator) is constantly monitoring him and the code he is writing. This would become interesting because there are two minds approaching to solve single problem. There are many cases where you make obvious mistakes whether its syntactical or logical. You only come to know them once you compile and actually run the code. The navigator always thinks about the code simultaneously with driver so possibility of bugs reduces a lot.
After 45 minutes there would be a timer bell which will ring. Every pair has to get up at that time and come to a close circle for analyzing what they have done in last 45 minutes.
1) Explain their design approach and they started from which problem statement ?
2) What they did really good ?
3) What they think they should improve on ?
Different pair can start solving the problem with different problem statement. The goal at the end of 45 minutes is not to complete the problem but to analyze what they have achieved in that time and how to improve their skills.
Interesting thing for every new session is that after every 45 minutes you have to DELETE your code. Yes you are not allowed to keep continuing from any of the part you have designed in earlier session. Also you have to switch the pairs. You will start again afresh with a new pair. And guess what, every new time you will be treated with a new set of constraints which you have to keep in mind while coding.
Some of the constraints are as follows:
- No Getters / Setters
- No Primitive Datatypes
- No more than 4 lines of code per method.
- Only constant variables and methods in the classes we design. (No mutable objects)
- Only const parameters to be passed.
- No addition of a new class unless you require it.
These constraints made all of us think a lot. Every time there is a new constraint imposed.. We have to re-think the solution entirely different way. This helps us lot about many such issues which are present in our production code but we never really think they even exists.
There are many good approaches came out by different pairs to solve the same problem. Some of them include:
- Combining snake and ladder in a generalized class which just specifies (start point, end point) pair. and reduce maintenance of one extra data-structure.
- Using event driven mechanism where if any player reaches any snake or ladder, an event will be raised to change the position of the player. This will help reducing the number of checks to be made for every move.
- By imposing only const data members we came up with a design for changing the entire "world" (Game class) for every state change. Going towards truly functional programming.
This made us realize that how much our code "Sucks" and how much we still have to improve on. If we start applying various constraints like this to our actual code, the output would be fully tested code which is of very high quality. We never over-engineer anything unless its needed. In our design we never created "Board" class which would have been the very first class which will come to our mind while designing the game.
Also at the end we discussed practical usage of TDD. Most of us are working on so called "Legacy code" and only very few will have luxury to start a project from scratch. How do we use the TDD to our advantage on this kind of scenario. In most cases we should start with functional tests and behavioral tests of our code and then later to go deeper to have unit tests like this.
We had lot of fun during the entire day.. I am sure that everybody who attended this sessions worldwide would have enjoyed it.


