If you are looking for some new ideas for your next coderetreat your are in the right place. This posting describes a second set of 13 session practices for coderetreat. The first set can be found here. Most of these practices are well known in the community or have been already used my own coderetreat practice, but some just came in my mind when writing this post. If you use one or another of the session practices below, please provide a short comment about your experience with the particular practice you used.
#21 Grid with fixed size
Per default, the GOL grid has infinite size and so, has no border. In this session you have to respect a grid with fixed size, e.g. 3×3 or 4×4. Cells on the border don’t have eight neighbors so you have to find a solution how to handle calculation of neightbors for these cells.
#22 Grid without border
This is the default GOL grid nature. But, in case you are accustomed to fixed size grid it’s probably an interesting alternation.
#23 Choose any three
There are four properties of Simple Design:
- All tests are green
- No code duplication
- Meaningful names
- As little code as possible
Choose any three from this list and examine after this session, whether something went wrong with your code because of the missing fourth property of Simple Design.
#24 Focus on 3-A
Unit tests should satisfy the 3-A-pattern: Arrange-Act-Assert
Each method should group these functional sections, separated by blank lines:
- Arrange all necessary preconditions and inputs.
- Act on the object or method under test.
- Assert that the expected results have occurred.
From my experience, this structure isn’t practiced often when writing unit tests. So, it’s probably a good session practice for your next Coderetreat. Assemble-Activate-Assert is a pattern that is nearly similar.
#25 Von Neumann Neighborhood
Normally, the 8-cell-Moore Neighborhood is used to calculate number of living neighbors in GOL. You could alternate this strategy by using the 4-cell-Von Neumann Neighborhood where the cells diagonal neighbors don’t count.
#26 Integration tests only
In TDD, the focus is on unit tests that have the right granularity to help a pair of developers to test the method that is developed right now and to ensure that all the other methods still work as expected. In this session only a really coarse grained unit test is allowed that checks the right result when calculating the next generation of GOL. You will realize that this test goes green the first time when your implementation is nearly finished. I case there is a bug in your code the test will probably not help you to identify the source of the bug.
#27 Truck factor session
In the middle of the session one member of the pair isn’t longer available and must be replaced by a peer from another pair – which happens to each pair. In this session you practice how to introduce a new peer to a task in progress and how to become acquainted into a new job.
#28 TDD randori session
A TDD randori is a format where only one pair is working on the given problem (e.g. GOL). The IDE of this pair is shown to all the other participants of the retreat by using a beamer. After three minutes or after finishing a (test) method the navigator or pilot leaves the pair and one member of the audience takes the free seat. After three minutes or the next (test) method the last remaining member of the pair that started the session leaves his seat and another member from the audience takes his seat. This procedure proceeds every three minutes or after finishing the next (test) method ’til the 45 minutes are over.
#29 No shortcuts
Most developers are accustomed to use dozens of shortcuts in their IDE within one minute of coding. In this sessions using shortcuts is forbidden. Developers often get into trouble the moment they have to click on menu entries to run their IDE. Nevertheless, this session is a lot of fun … after the first wave of swearing is over.
#30 No tests
Unit tests is what makes responding to change easy. In this session we skip writing tests alltogether. By doing so, we have no idea whether our solves the problem or not. After this session you are happy that you are accustomed to write unit tests in your daily programmer’s life. This session can be easily combined with session #31.
#31 Tests as an afterthought
In this session you need the code from a prior session (which you didn’t delete). In case there are unit tests, please, delete these tests. Focus of this session is to try to understand what the pair that produced that code without tests intended and to proof your assumptions by writing the right tests. After you produced an adequate test quality, feel free to refactor the code in question.
#32 Do something
Focus of this practice is to use meaningless names in classes, methods and attributes, in code and tests as well. Probably you have experienced a lote of doSomething() methods and MyClass classes in your programming carreer. Goal of this session is to understand the value of meaningful names.
#33 Waterfall-driven development
When practicing TDD you write or change one single unit test and then write or rewrite one single public method (and probably some code that has to exist behind the scene). Try to write all the tests you think you will need to solve the GOL (or your particular goal) beforehand. Then, try to produce the GOL code step-by-step or method-by-method and see, whether your assumptions about testing have been right. They are probably not complete right and you learn once again why focussing on tests you need right now is an good idea instead of writing tests the waterfall-driven way.