Code Retreat is a day-long, intensive practice and learning event, focusing on the fundamentals of software development and design. By providing developers the opportunity to take part in focused practice, away from the pressures of “getting things done”, the Code Retreat format has proven itself to be a highly effective means of skill improvement. Practicing the basic principles of modular and object-oriented design, developers can improve their ability to write code that minimizes the cost of change over time.
Software developer improves their skills in the basic principles of modular and object-oriented design.
A Code Retreat is the place where a software developer can practice all the things he should do, but he doesn’t because he doesn’t have time to. For example TDD: Every software developer knows that TDD is a good thing, but he never has the time to practice it. If he had time to practice it, he would become faster and he would be able to apply TDD during his daily business.
The Code Retreat is the place where any kind of methodologies, tools and 3rd part libraries can be learned.
In other words: The Code Retreat is the place where a software developer learns how to write the perfect code!
- A small, well-known problem like: Conways Game of Life
- A focus like:
- A methodology that needs to be practiced, like: TDD
- Or a software design principle that needs to be practiced, like the Single Responsibility Principle
- Or a 3rd part library that needs to be learned, like the use of a state machine, or using dependency injection, or the use of a new mocking framework, or …
A group of software developers are solving a part of the problem (e.g. the rules for the state of the cell in the Game of life problem). Always two developers code together (Pair Programing). They practice together during 45 minutes. They don’t want to solve the problem; they want to practice TDD, some patterns, some tools or some 3rd part libraries, or whatever the team is focusing on.
If the team only writes one single line of code within these 45 minutes, it doesn’t matter, as long as this one line of code is perfect.
During the coding a coach is supporting the pairs, if there are any questions. He also might give some hints, like how for example the tool also could be used.
In order to have fun, while coding, different boundary conditions might be applied. This might be a condition like: Don’t talk to each other or only use immutable objects (thread-safe) or don’t make use of the mouse; only use the keyboard and shortcuts!
Another popular boundary condition is the ping pong pair programming pattern, where one person writes the unit test, the other tries to get the test green as fast as possible. The implementation might be done in a way, which forces the test-writing person to write another test to make sure the implementation is solving the problem as it is supposed to do.
After 45 minutes all developers are being asked by the coach to share their experience. In this Retrospective every team member shall answer the following questions:
- How could they handle the given constraints?
- Was this cycle useful?
- Did they make any improvements compared to the preceding cycle?
- Are there any questions so far about any topic that the focus was about?
After this Retrospective, the just written code is either deleted or at least put away. The reason for this is to ensure the team members are open in every cycle for new ideas.
Before starting the next cycle, the team shall have a short break.
For the new cycle every team member seeks a new coding partner. And they start coding from scratch for another 45 minutes. This time the coach may enforce other boundary conditions.
- At least one pair of software developers
- A coach, that explains the rules, defines what to focus on and probably explains the problem, the methodology the team wants to learn. He also defines the new boundary conditions, as described above
The output will be some code that will be thrown away!
But the output will also be some new knowledge about whatever the focus was during the day. Each single developer will gain proficiency in writing code. They were trained and are now aware of what it means to write the perfect code.
Tools / Templates
An IDE, depending on what the Code Retreat focus lies on, ideally the IDE the team works usually with.
Coding Dojo or Code Retreat?
The goal of the Coding Dojo (see Service Item Coding Dojo) is to learn how to write code perfectly. Meanwhile, the goal of a Code Retreat is to learn how to write perfect code.
The Code Retreat is more suitable, when you want to:
- Learn a new tool or methodology; the Code Retreat is an initial booster for learning something.
Let’s say, you want to introduce TDD to the team.
- Ramp-up new team members; in the Code Retreat the new team members can learn how to work with the tools and 3rd part libraries, the team is using.
E.g. the team uses a certain dependency injection library. The Code Retreat is the place to teach the new team members how to use this library.
- Improve the skills of the team.
The Coding Dojo is more suitable, when you want to:
- Practice the usage of the tools and methodologies; the Coding Dojo assures that the developers are professionals in the use of the methodology or tool.
After several sessions, the team will apply TDD, while they were sleeping.
- The new team members to understand the team-understanding of how to write code in this particular team.
- Keep the team on the current level of skills.
So, a Code Retreat is the place for learn something new, while a Coding Dojo is the place for practicing something the developers already know.
- As a coach you are responsible that the problem is understood by the team, otherwise the team tends to focus on the less difficult and less important stuff such as handling of button clicks.
- It’s important to guide some team members, in order to make sure, that the code they write is really perfect. Give hints. If necessary, explain on the whiteboard to everybody.
- Usually it’s useful to time-box the retrospective to 15 minutes. Since it’s all about writing the perfect code it might make sense to extend this 15 minutes and discuss about advantages and disadvantages of the just written code.
- As a coach you have to be strict: After 45 minutes the time is over, the written code shall be deleted (or at least archived) and the team shall have a break.
You’ll realize that some team members can’t stop coding…
- The Code Retreat is the place where the software developers have time to learn new methodologies or tools. Therefor it’s important that the code has no relation to the real world problems of the developers. Writing prototypes during a Code Retreat would be a misuse of the Code Retreat!
- As a coach you should supervise which pairs the developers are building. It’s useful that the team is building other pairs than they would do on a usual working day.
Pair a senior developer with a junior!