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.

universe-with-wormholes
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.

Purpose

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 →

Legacy Coderetreat: Episode 3 – Fix bugs on Legacy Code – Code Cast

Fix bugs on legacy code – code cast

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.

Code Cast

This is a code cast in Java. I have a bug report and I need to fix bugs on legacy code. I start by writing characterization test on the system level and then I dive into the code with writing a unit test. See more about the technique in the blog post Fix a Bug on Legacy Code.

 

Legacy Coderetreat: Part 4 – Fix bugs on Legacy Code

Fix bugs 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.

Purpose

When we need to fix bugs on legacy code, we first need to understand if the described behaviour is in fact a bug or not. For that we can write some characterization tests in order to understand what the system really does. The simplest form of characterization test is a system test. A couple of ideas to start writing the characterization tests are to use the generic approach Part 2 – From Nothing to System Tests and Part 3 – Golden Master. We can generate system tests considering that the System Under Test (SUT) is a black box. You can find more details about how to do that in the blog posts and code casts about the above techniques. But in order to fix bugs on legacy code we need to dive more into the code base. We need to write tests on a smaller scope and we often need to refactor in order to make room for the code changes. Let’s see a technique of fixing a bug in legacy code.

Fix bugs on legacy code

Fix bugs on legacy code

Read More →

Legacy Coderetreat: Episode 2 – Golden Master Codecast

Golden Master Codecast

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.

Code Cast

The Golden Master technique is very useful when a clear input and output is easy to obtain on the system level. There are some cases where the Golden Master technique can be applied with difficulty or where it cannot be applied at all. We will discuss these situations further as well.

For all the given situations we need to think if the system tests generated with the Golden Master are enough, or we need to start adding other types of tests like unit tests, component tests, integration tests, security tests, etc

After this session we will have a basic safety net composed of system tests. These system tests will check the SUT against the golden masters. A very important output of the system would be the golden masters persisted in any form. All the system tests would need always to be called during the next refactoring phases.

This is a codecast in Java where I start generating system test with the Golden Master technique. Please read more details about this technique in the Part 3 – Golden Master blog post. Have fun!

 

 

 

Legacy Coderetreat: Part 3 – Golden Master

Golden Master 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.

Purpose

Whenever you start dealing with an existing software system you need to have a basic safety net. This basic safety net will make sure that whenever you change big things in the code, the changes will not affect the existing functionality. You can read more about this concept in the generic session Part 2 – From Nothing to System Tests.

As mentioned in the above entry, we want to start with some basic safety feature that will let us test the code in a generic way, focusing only on inputs and on outputs and without changing the production code. So we will treat the system as a black box (we do not care about the internal behaviour of the system, we care just about the whole system inputs and outputs) and we will test only the outputs for given inputs.

The Golden Master technique is very useful when a clear input and output is easy to obtain on the system level. There are some cases where the Golden Master technique can be applied with difficulty or where it cannot be applied at all. We will discuss these situations further as well.

golden-master-beatles-hey-jude-lp

In audio mastering, a golden master is a model disk used as a reference to create disks in the old vinyl industry. This disk was cut in metal and it would contain the sound transferred from a microphone (see here more details). In the software world we took this name and we started using it for a fixed reference of a system output, paired with a system input.

Read More →

Legacy Coderetreat: Episode 1 – From Nothing to System Tests Codecast

From Nothing to System Tests – Codecast

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.

Codecast

Before starting to change any legacy system you need to know you will not introduce any defects when changing the code. So one way would be to stay on the safe side and start writing some automated tests. These tests can be Golden Master type of tests, they can be Characterization Tests, or anything else that might give you this certainty of correct changes in a later stage.

This is a code cast in Java where I start covering with tests a simple code base. Please read the explanation of this technique in the Part 2 – From Nothing to System Tests blog post. Have fun!

 

This session has some prerequisites:

  • Good knowledge of unit testing and test doubles, especially mocks, stubs and fakes.
  • Very good knowledge of the programming language you use. You often need to use some hacks that will allow you not to change the existing code and be able to test it.
  • Open mind to new, sometimes mind-blowing, techniques and concepts.

Further it is very important to have good knowledge about software design, especially techniques of decoupling the existing code. It would be a good thing that any attendee would know about the SOLID Principles and have basic knowledge about Design Patterns.

Legacy Coderetreat: Part 2 – From Nothing to System Tests

From Nothing to System Tests

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.

Purpose

Whenever I need to change an existing system I need a safety net. These system tests knit a coarse safety net, very good if you want to have the safety of changing code later without introducing defects.

This is the first thing I usually do when I start working with a system that:

  • does not have any automated tests
  • is totally unknown to me

This safety net will be used during the next phases when the code will be refactored and cleaned-up, before being modified. Now let’s see a bit about the concept of this session.

from-nothing-to-system-tests

From Nothing to System Tests

Read More →

Legacy Coderetreat: Part 1 – Introduction

Legacy Coderetreat

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.

A bit of history

On 26 November 2011 I had the honour of being an attendee at the second ever Legacy Coderetreat, which was supposed to be the first one in the world. But my friend Johan Martinsson from Grenoble beat Erik and me to it. Anyway I was part of the second ever Legacy Coderetreat in the world, facilitated by JB Rainsberger. JB had come with this concept of using the Coderetreat format, but for legacy code.

At the beginning of the day he presented us the problem, like in any other coderetreat. The problem was an ugly trivia game and you can find the sources here. At that time the code base was translated, from Java, only in a couple of other languages. Now you can find almost any language you want, thanks to the worldwide community of passionate developers who translated the code base.

JB facilitated the event like you could find in here, with a lot of details. But in short we would start with a free session, then follow with Golden Masters, continue with Subclass to Test, Replace Inheritance with Delegation and then Pure Functions. After each iteration we deleted the code like in any other coderetreat and swapped the pairs.

I liked a lot the fact that JB started this idea, because I am a big lover of working with legacy code. And this Legacy Coderetreat is such a good way to practice. But I had some other ideas on how to make it different.

legacy-coderetreat

Legacy Coderetreat

Read More →

A community event: Bring your own code

Bring your own code

Last month I started a new community event idea. It is called “Bring your own code”, and I “stole” it from what Antoine Vernois is doing in the Toulouse Software Craftsmanship Community. You can find here the event page. Tomorrow we will have the second edition that you can find here. Let’s go a bit into the mechanics of this event type.

Why

  • You have a project and you want a second opinion.
  • Your code needs improvements and you do not know where to start from.
  • You just like to show some awesome code and give it as an example.
Bring Your Own Code

Bring Your Own Code

Read More →