Code retreat ? Can you enjoy a retreat with code ? A code retreat for a whole day with unknown people across different companies and with whom you have never met and seen ? Though I had been involved in many coding dojo sessions inside SAP with known people and teams as a lean and agile practitioner, I had my own perspectives on the event - but this one turned out to be different !
As part of the pre-conference workshop on Agile and Lean Software Methods 2014, I had a chance to participate in a full day code retreat facilitated by Corey Hayes, one of the pioneers of code retreat events. The pre-requisites for such hands-on events are of course, a fully charged laptop with a pre-configured development environment and to be comfortable in any one of the popular programming languages (Java, Ruby, Python etc.,).
The day started with a short introduction of one self and any open wishes to get exposed to a new programming language from the audience. After a quick round of introduction, the facilitator gave a very high level introduction to the Conway’s Game of life puzzle and asked the participants to start forming coding pairs to solve the problem in one’s preferred programming language.
The first session (Session1) started and time limit was 45 minutes. I paired with a very young programmer from a young company and we coded in Ruby. It was fun and coded two classes cell and grid with two coordinates. The first session ended and the facilitator asked us few questions on how flexible our code is - to accommodate new changes in the requirements like additional dimension (from x,y to x,y,z) and the quality of our unit tests. It was also the rule that at the end of each session, we have to delete the code and form a new pair. Before the start of the second session, the four simple rules of design was introduced by the facilitator.
The second session started with a design constraint of not using any boolean variable in the code. We started to code in a test driven way in Java. Instead of using Boolean variable, we split the behaviour into two concrete classes (LiveCell and DeadCell) and with many other design decisions along the way. At the end of 45 minutes, our code was much better than the previous session and we made some progress, but it wasn't still perfect ! Then came a lunch break.
After the lunch break, we reassembled and then came a new design constraint for the third session – no methods with more than 3 lines of code. The reasoning behind such a design constraint is to achieve a consistent level of abstraction in our code. Most of our code had a branching inside the method which caused ,,procedural polymorphism”, instead we should have used type-based polymorphism (branching with classes). With the new coding partner with no baggage to carry (Remember, we need to throw away the old code before we start !), we made a significant progress with a code in a better shape than the previous.
Third session ended and came the last session of the code retreat with additional design constraint. This time it was – elimination of return statements. The idea is to keep the data closer to its operation. It was pretty tough to adhere to this constraint using Java language. Of course, we used anonymous inner classes, but the solution wasn't elegant. People who were coding in Ruby, Python could accomplish their task with little effort. The session ended and we couldn't finish solving the problem in our code. The facilitator told us that the solving the problem wasn't the true intention but to hone our skills on clean code. I believe, we achieved our objective :smile: and the code did improve..
I recommend such types of code retreats to most of our development teams during sprints. Why ?
Because I believe, software craftsmanship comes only with deliberate practice. There is a huge difference between knowledge and skill. I know, most of us as developers do have knowledge about clean code principles like small methods, DRY principle, and some of the code smells like conditional complexity, procedural polymorphism etc., But, unless we deliberately practice to produce clean code, there is no way to enhance the quality of our code. It takes time to practice, to learn, to unlearn from old habits. Writing bad code is bad and would lead to bad inventory which can go uncontrolled. We all know that one of the lean principles is to eliminate the uncontrolled inventory and to bring in quality in our core work. I believe, such Code retreats provides a platform for good agile teams to become great by sharing and amplifying their knowledge !
