Monthly Archives: November 2014

You are browsing the site archives by month.

Coding Games – video at xALEc

Coding Games

This is a video about Coding Games from xALEc where I am part of a conversation about how one could teach programmers to be better by using games and pair-programming.

Coderetreat: The toughest constraint

Coderetreat: The toughest constraint

Ask the attendees what they want

During the Global Day of Coderetreat 2014 (GDCR) I facilitated the event in Turku, Finland. That is when I presented the toughest constraint ever in any coderetreats I facilitated until now.

Since I have a lot of constraints in the list, some time ago I started to ask the attendees how difficult would they want the constraints to be. I am asking them on scale from 1 to 5, 1 being boring, and 5 being extremely difficult, what would they want to do as difficulty.

Another thing I’m doing, stealing the idea from Alex, is to ask the attendees of the coderetreat about the expectations they have. They write one expectation on a sticky note and we look at them and they choose what they want to practice. I tell them about constraints that will generate the kind of learning they want.

Usually during coderetreats the attendees want constraints of the difficulty between 2 and 3. Probably because 1 seems boring and 5 seems scary.

The constraint

Now it was different. They wanted the scary constraints. And they insisted. So here is the constraint.

Read More →

Legacy Coderetreat: Part 5 – Add features on Legacy Code

Add features on legacy code

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.


When we need to add features in legacy code we need to make sure we understand it. But the feature needs to be added to an existing system. For that we need first of all to understand the current behaviour of the system. After that we need to make room for the change by refactoring the existing code. Of course we need a safety net before refactoring the existing system. Once we have room for the new feature we can alter the existing system. The main purposes of writing tests before adding the feature would be first of all to make sure we do not introduce defects and secondly to make sure we add the wanted feature. By having tests written for the new feature we can validate them with our product colleagues.

During the next section you will find the steps to take in order to minimize the risk of introducing defect or adding the wrong feature to legacy code, what you would do at a legacy coderetreat.

Add features on legacy code

Add features on legacy code

Read More →