Coding

Openbravo´s First Coderetreat Event Was a Success!

Last year, we at Openbravo learned about Coderetreats, a day-long, intensive practice event focusing on the fundamentals of software development and design. My colleague Gorka Gil and I were immediately interested, and we attended the Coderetreat hosted at the ThinkTic facilities in Logroño (we wrote a blog post about our experience that day).

We liked it so much that we didn’t hesitate to organize a Coderetreat ourselves, to bring the event closer to the software developer enthusiasts of our community. Openbravo readily offered to host the event at  its headquarters, and to pay for the breakfast and lunch.

So, after some weeks of preparation, we hosted the event  on October 22nd, the Global Day of Coderetreat. It attracted a good mix of students and more experienced developers, eighteen people in total and all of them eager to practice and to learn more about their craft.

We started the day by explaining what a Coderetreat is and we then asked the attendees to introduce themselves and to tell us their current occupation, their programming languages of choice and their previous knowledge of the Test Driven Development (TDD) methodology.

Given that this was going to be the first TDD experience for most of them, we did a brief introduction on the three steps of TDD:

  1. Write a unit test that fails;
  2. Write the minimum amount of code necessary to make the test pass;
  3. Refactor the code to adhere to the best practices of design and development, making sure the tests remain green.

The programming languages the attendees were most interested in trying were Java, PHP, Javascript and C#. Other less common choices were Matlab, C and Google´s Apps Script.

After the introduction we all headed to the kitchen to have breakfast.  It was a good opportunity to break the ice and to fuel up in preparation for the day of intensive development ahead of us.

We wanted to start nice and easy — it was early Saturday morning after all! — so in the first session we did not introduce any additional restrictions: the developers just had to pair up and do their best to write a clean implementation of Conway´s Game of Life using Test Driven Development.

Those who had their development environment ready could start right away figuring out how to address the problem, while others had to spend the beginning of the session setting up a development environment with a test infrastructure.

For the second session we told them to try the Ping-Pong pairing technique, where one member of the pair writes a failing test, the other then makes the test pass and refactors the code. Then the second developer writes the next failing test, the roles being switched constantly. With this we intended to have each of the developers try the three steps of TDD.

We added two additional constraints to the session: a limit of four lines per method and the restriction of not using conditional structures in their code. The second restriction was particularly interesting and it led to a discussion about polymorphism and lookup tables.

By this time, people were already getting familiar with Conway’s Game of Life, so Gorka and I introduced the Evil Mute Pair Programming restriction in the third session. In this pair programming variant, the members of the pair are not allowed to talk, and the developer that took care of the second TDD step had to try to make the test pass but with the wrong implementation.

This put the focus on writing very expressive tests to overcome the no-talking restriction and to write a set of test cases complete enough to force replacing the wrong implementations with proper ones.

The third retrospective went longer than the previous ones because we had to wait for the pizzas and tortillas to come!

We took advantage of that extra time to talk about some of their development habits. Fran Naranjo, one of the most experienced attendees, proposed that we talk about how we comment our code. Do we use comments at all? If we do, where do you place the comments? Do we write comments in English or in our native Spanish? Are all comments good, or may some of them be the sign that our code is not clear enough?

Then we headed back to the kitchen for the lunch break. After three hours of non-stop developing, people were hungry and the break was most welcomed. 

Taking a well-earned rest
Taking a well-earned rest

For the fourth session, we planned a very energetic constraint to fight the sleepiness that usually comes after having lunch. The constraint is called Taking Baby Steps. Developers had four minutes to write a failing test and to write an implementation that fixed it. If after the four minutes the test is still failing, they have to start over. If the test passes, they will spend the next four minute session refactoring the code.

Even though four minutes seems like plenty of time to write a small test and make it pass, it is harder than it looks. They had to focus a lot, making every second count. After a few four-minute rounds people were starting to relax , so we introduced a new constraint: they were not allowed to use the mouse.

This restriction forces coders to use keyboard shortcuts and most of the time, working with shortcuts is faster. but only if you are very familiar with your development tools.  During the retrospective we talked about some of Eclipse’s source and refactor actions, which can save us quite a lot of time.

As the previous sessions had been very challenging, for the final one we introduced two less artificial restrictions that would allow the developers to focus on doing a good design.

The first restriction forbade the use of primitives as input or output method parameters, they were only allowed in the class constructors. This is a way to prevent a development bad practice called primitive obsession.

The second restriction consisted of introducing modifications to the original problem, to see how they adapted their design. This restriction paved the way to talk about how our designs should follow the Open/Closed Principle, meaning they should be open for extension but closed for modification. This is one of the best ways to design a solution that minimizes the cost of change.

In the final retrospective, the attendees had to answer three questions:

  1. What if anything, surprised you today?
  2. What, if anything, did you learn today?
  3. What, if anything, will you do differently on Monday or in the future?

The participants all seemed to enjoy the event, at least I hope they did!. Most of them liked working with TDD, but they wanted to practice more before trying to apply it in their daily job. I certainly loved it, and it was great to have in the same room such a talented group of developers  with the drive to keep practicing to reach their full potential.

Watching them work reminded me of this great quote by Robert C. Martin (aka Uncle Bob, author of the must-read books Clean Code and The Clean Coder).

Clean code always looks like it was written by someone who cares

We are looking forward to organizing and hosting another Coderetreat in 2017! I think that we as facilitators also learned a lot, and we can apply that knowledge to make next year’s event even more challenging, educational and satisfying. I hope to see you there!

Many thanks to Pablo Lujan for the nice pictures he took. The full gallery is available here.

Previous post

New Feature: Usability and analysis improvements in Openbravo Analytics

Next post

This is the most recent story.

No Comment

Leave a reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>