1. CODE RETREAT
$
PROGRAMMERS HONING THEIR CRAFT TOGETHER

2. WHAT IT IS?
intensive practice event,
 focus on the fundamentals of software development
and design,
 focus on skill improvement.


3. WHY WE DO IT?
learn through pairing,
 extend your comfort zone,
 practice,
 experiment,
 learn new practices.


4. HOW WE DO IT?

Normally:
organized Saturdays,
 it takes a full day (6 sessions).


This code retreat:
organized Wednesday (October 23rd, 2013),
 it takes only 3 hours because of work constraints (2
sessions).


5. HOW WE DO IT?

introduction - 30 min
first session – 45 min
 retrospective for first session – 15 min


break – 15 min
second session – 45 min
 retrospective for second session – 15 min


final retrospective & closing

6. HOW WE DO IT?
only pair programming,
 switch pairs when session ends,
 use any language
(preferably C# or Java for this retreat),
 delete the code when session ends,
 do not try to finish the problem,
 focus on practice,
 enjoy!


7. WHY USE CONSTRAINTS?
learn new things,
 expand our comfort zone,
 improve the way we design software,
 learn communication through tests
(tests as a form of documentation).


8. WHAT CONSTRAINTS?
the four elements of simple design,
 no conditionals (if, while, etc),
 no primitives (int, boolean etc, just objects),
 four lines of code per methods,
 law of Demeter (use only one dot per line),
 no mouse/touchpad (keyboard only),
 no IDE (text editor only),
 taking baby steps,
 object calisthenics,
 immutable objects only.


9. WHAT? PAIR PROGRAMMING GAMES?

ping pong (one person writes the tests, the other
person writes the implementation code to make the
test pass),

mute pairing (no one talks, this improves the
readability of the code),

mute with find the loophole (AKA evil coder; the
implementation person purposely writes the wrong
algorithm that still makes the tests turn green. The
key is that they have to keep the code very clean all
the while. So, no big long if statements parsing on
the input parameters.)

10. WHAT ARE THE RULES FOR
PING PONG PAIR PROGRAMMING?
driver – the one coding at a given moment
 copilot – the other developer

1.
2.
3.
4.
the driver writes a test and then hands the
keyboard to the copilot,
the new driver makes the test pass,
they refactor together, passing the keyboard as
necessary,
they reverse roles and start over with a new test.

11. WHAT ENVIRONMENT?

C#
Visual Studio IDE (preferably with ReSharper)
 NUnit testing framework


Java
Eclipse or IntelliJ IDEA IDEs
 JUnit testing framework


git bash (or any other git client)

12. WHAT DO WE CODE?

traditionally the Conway's Game of Life,

can also be Tic-Tac-Toe, but this has a small
disadvantage: you might be able to finish it in a
session which is not so good.

13. WHAT ARE THE RULES?
having an infinite 2D orthogonal universe
 being given an initial generation called seed
 the following rules are applied simultaneously






live cells
live cells
live cells
dead cells
revived
with
with
with
with
< 2 live neighbors die
2 or 3 live neighbors live
> 3 live neighbors die
exactly 3 live neighbors will be
check this online simulation to understand better how it works.

14. FIRST SESSION
you have 5 minutes to get prepared,
 pick your pair,
 use ping pong pair programming,
 don’t use constraints,
 just get a feel for the problem domain,
 start coding (and the countdown timer)!


15. FIRST SESSION’S RETROSPECTIVE

do you find it easy to delete the code?

why do you think we should do that?

what would happen if you didn’t delete it?

16. 15 MINUTES BREAK!!!

17. SECOND SESSION
you have 5 minutes to get prepared,
 pick your pair (different than in the first session),
 use ping pong pair programming,
 pick a constraint,
 start coding (and the countdown timer)!


18. SECOND SESSION’S RETROSPECTIVE
is an array the right way to store the cells?
(talk about the “primitive obsession” code smell),


what constraints did you choose and why?

19. FINAL RETROSPECTIVE & CLOSING

what, if anything, did you learn today?

what, if anything, surprised you today?

what, if anything, will you do differently in the
future?

what can be improved regarding the organization of
the code retreat?

20. WANT MORE?
Global Day of Code Retreat (#gdcr twitter hash
tag),
 This year on December 14th,


Legacy Code Retreat – practice writing tests,
refactoring, improving the design in existing code
(since many of us don’t have the privilege of
working on a greenfield project),

Coding Katas – programming exercises which help
the programmer to improve his/her skills through
practice and repetition.

21. RESOURCES
Links and books of interest

22. LINKS
video introduction to code retreats
 how others do it: The Orlando Code Retreat Video
 main site: coderetreat.org
 awesome site by Uncle Bob: cleancoders.com
 coding kata catalogue
 the software craftsmanship movement
 software craftsmanship community (contributor
there)


23. BOOKS
Clean Code
by Robert C. Martin
The Coding Dojo Handbook
by Emily Bache
Refactoring
by Martin Fowler
Working Effectively
with Legacy Code
by Michael Feathers

24. APPENDIX
Detailed descriptions for the constraints

25. THE FOUR ELEMENTS OF SIMPLE DESIGN

The code:
passes it’s tests (tests always on green),
 minimizes duplication (extract methods),
 maximizes clarity (better names, SRP, etc),
 has fewer elements (less code is better most of the
time).


26. NO CONDITIONAL STATEMENTS
no if/while/switch etc statements
 the conditional operator (?:) is permitted
 boolean expressions are also permitted
 you can also use maps instead of switches


27. NO PRIMITIVES
with this we’re trying to fix the “primitive
obsession” code smell,
 it basically means that you shouldn’t use primitive
data types (int, double, boolean, string) to
represent domain ideas,
 we introduce a Value Object in place of the
primitives, and other code spread around will be
moved in the Value Object,
 this is a way to minimize duplication.


28. FOUR LINES OF CODE PER METHOD
programmers have a way of being “comfortable”
with the code: instead of creating a new method for
something (too hard), they add code to an existing
method making it bigger and harder to test (that is if
they have tests at all),
 this constraint will force you to use SRP (the Single
Responsibility Principle),
 an easy way to do this is “extract till you drop”
(see Uncle’s Bob Clean Code book) which tells that
you should extract new methods from an existing
one till you don’t have anything else to extract.


29. LAW OF DEMETER – IN PLAIN ENGLISH
also called the principle of least knowledge,
 your method can call other methods in its class
directly,
 your method can call methods on its own fields
directly (but not on the fields' fields),
 when your method takes parameters, your method
can call methods on those parameters directly,
 when your method creates local objects, that
method can call methods on the local objects.


30. LAW OF DEMETER – FUNNY DEFINITION
you can play with yourself,
 you can play with your own toys (but you can't take
them apart),
 you can play with toys that were given to you,
 you can play with toys you've made yourself.


Real Life™ analogy: when one wants a dog to
walk, one does not command the dog's legs to walk
directly; instead one commands the dog which then
commands its own legs.

31. NO MOUSE/TOUCHPAD (KEYBOARD ONLY)
programmers who know keyboard shortcuts (to
build, to run tests, to execute) work faster and are
usually less distracted,
 you should learn the keyboard shortcut equivalents
for most of the operations you usually do on the
normal work day,
 you should know the Windows ones too:

Win + E  open new explorer window,
 Alt + D  go to address bar,
 etc.


32. NO IDE (TEXT EDITOR ONLY)
this is addressed to those that work the entire day
in an IDE (Visual Studio, Eclipse, IntelliJ IDEA,
others),
 do you know what the IDE does (what commands,
what parameters) for you when you
compile/build/deploy the code?
 can you manage to put the imports/usings by hand?
 can you work without syntax highlighting? Using
just Notepad (no Notepad++).


33. TAKING BABY STEPS

a small step is sure and steady, whereas when taking a large step you
could be in danger of breaking the tests.
Steps - credits to Adrian Bolboaca
1.
2.
3.
setup source control repository,
setup a timer for 2 minutes interval when you start,
write exactly one test:
A.
B.
4.
5.
restart timer (no discussions in between timers),
refactor
A.
B.
6.
7.
8.
if the timer rings and the test is red then revert and start over,
if the test is green before timer rings then commit.
if the timer rings and the refactoring is not complete then revert and
start over,
if the refactoring is complete before the timer rings then commit.
restart the timer (no discussions in between timers),
go to step 3,
when session time is up delete the code.

34. IMMUTABLE OBJECTS ONLY
no setters for object fields,
 easier to debug code when there’s nothing that can
mutate,
 extremely helpful when dealing with concurrency,
 applicable to value types.
