Category Archives: Craftmanship

Facilitating the Global Day of Coderetreat 2013 in Amsterdam

On the 14th of December 2013 – the Global Day of Coderetreat was held at ZilverlineI have experience with coderetreats and also organised one at the 7th of january in 2012, and the GDCR12.

This time I both hosted and facilitated this event. This means that besides practical stuff I also did the talking which I will explain further in this post. This was the first time I did this and I’d like to share how it was. If you want to get an impression of the day you can have a look at this slideshow.

A big thanks to Bob Forma and Diana Sabanovic who helped me with the hosting aspects throughout. This enabled me to mostly focus on facilitating.

I was anxious, especially since last years GDCR was very well done. Back then I had a great experience and I was not sure if I could give the participants the same experience. Yet, I wanted to do this: I just love sharing knowledge and give people something to learn or think about.

After attending the GDCR Facilitator Training by Jim Hurne, I had a clear image of how I wanted the participants to experience the Coderetreat: People having fun, learning from each other and the constraints given.

Thats it.

Continue reading

A Randori with Corey Haines

Saturday 8th of September 2012.

I came to Amsterdam Amstel train station, to pick up Corey Haines who I had asked if he wanted to meet the local community in Amsterdam and have some fun coding.

After I first introduced myself to a complete stranger (I swear he really looked like Corey Haines :))…
I then walked to (the real and smiling) Corey Haines and got us to the car to get to our location.

It was a fun evening coding. Around 10 people came and we mainly focussed on coding. I want to share one of the highlighting moments (to me) of that evening.

A Randori.

I never did a Randori before, but I really liked this form of group programming, so let me share this with you. Perhaps you might want to try it yourself with a group of developers you know.

So what is a Randori?
If I had to put it in one sentence: A Randori is a pair-group-rotating-programming session.

What we did
We did a Kata, but not all by ourselves… we did it all together.

Doing a Kata on your own is fun.
Doing a Kata with multiple people surely would be more fun right?

In this case we did the LED Display Kata.

But how did we do it as a group? Basically it works like this:
You have one person controlling the computer (called the Driver). Another person, called the Navigator, has a say in what should be made (design-wise). The Driver and the Navigator form a pair.

The rest of the people (the Audience) has a role as well:
When doing the Kata (in TDD of course), while you are in the red phase (test fails), the Audience must remain silent while the Driver and Navigator try to get the test to green (test passes). The Driver and Navigator may talk and work it out. Once the test is green, the refactor phase starts, the Audience is allowed to bring in suggestions. Want to shut up the audience? Write a failing test 😉

After a few minutes (in our case 5 minutes) you switch roles:
Navigator becomes Driver
Driver becomes Audience member
someone from the Audience becomes Driver

That’s a whole ‘session’. Reset the timer, and continue with the Kata where the previous pair left off.

Since you cannot write new code without a failing test, the Navigator is obliged to write (or let the Driver write to be more exact) a failing test first.

To avoid major rewrites of the code, there is a restriction to the Navigator. He may only refactor big changes after introducing an amount of new tests. Only when the tests pass, the Navigator may introduce major design changes.

So why is this fun?

It is fun for several reasons:
– It resembles a real world problem, where you have to work with existing code (and you can’t change the whole design because you feel like it).
– It’s fun to have short discussions about the code and its design
– You learn a lot from others when discussing code and design
– You learn how Java sucks by having no String.join() 😉

Picture or it did not happen!
Here you can see Corey Haines (at the left) in the session, looking at code that Arjen (at the right) is typing. And yes, I am taking this picture so you don’t see me on it of course! 🙂

Recap
Doing a Kata is a fun excersise alone. If you are with a group of people you could consider doing a Randori, and have fun coding together. The Kata itself is only the means to pair program, fix a problem, in existing code you did not write and trying to

Practical: What do you need
– A group of people (around 10 people)
– A computer with a dev environment installed (testing framework required)
– A big screen / a beamer

Thanks!
Special thanks to Corey Haines for coming over and let us have this experience!

Footnote: Later Arjen, Daniel and I had worked on the LED Kata again in a teamviewer session. We made a working solution (we wanted to crack the problem badly), which is also on Github.

The difference between TDD and Test First Development

Recently I promoted to do TDD, instead of “Tests First” development. Some people asked me what the difference is between them. In both cases we write tests first right?

So what is the difference?

I believe the difference is this:

Test First decribes your solution. TDD describes the problem

The difference could probably be explained best when using the coderetreat I had organized at the beginning of this year. Within this session I had experienced a great example to tell the difference between Tests first and TDD. To clarify the difference in this blog, we will be writing an implementation of Conway’s Game Of Life. It has the following rules:

  1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. Any live cell with more than three live neighbours dies, as if by overcrowding.
  4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

And it looks like this:

Image

Game Of Life in Action - Image from Wikipedia

Your assignment:

Write code that implements to the four rules above. It should be possible to apply these on an infinite grid

Test First describes your solution:
So the rules talk about “cells” and in your mind you’re already trying to solve this puzzle. In fact, I bet you’re already thinking about some array to put this matrix of cells into. Using a matrix we can easily determine neigbours and solve this puzzle…

We start with the first rule: “Any live cell with fewer than two live neighbours dies, …“.

We know it needs neighbours, so we need some boilerplate for that right?

The first test looks like this:

[sourcecode language=”java”]
public class CellTest {

@Test
public void mustReturnTrueWhenAlive() {
Cell cell = new Cell(1,0);
Assert.assertTrue(cell.isAlive());
}

}
[/sourcecode]

Since we’re doing TDD (atleast we think it is, we’re actually doing Tests First…), we need to create this Cell class to make it compile.

[sourcecode language=”java”]
public class Cell {

private long x, y;

public Cell(int x, int y) {
this.x = x;
this.y = y;
}

public boolean isAlive() {
return true;
}
}
[/sourcecode]

Before we can do anything with counting the number of neighbours, we need to determine what a neighbour is. Since adjecent cells are counted as neighbours, we start writing tests for this:

[sourcecode language=”java”]
@Test
public void mustReturnTrueWhenNextToAnotherCell() {
Cell cell = new Cell(1,0);
Cell adjecent = new Cell(1,1);
Assert.assertTrue(cell.isAdjecent(adjecent));
}

@Test
public void mustReturnFalseWhenNotNextToAnotherCell() {
Cell cell = new Cell(1,0);
Cell adjecent = new Cell(3,3);
Assert.assertFalse(cell.isAdjecent(adjecent));
}
[/sourcecode]

And along with it the code:
[sourcecode language=”java”]
public class Cell {

private long x, y;

public Cell(int x, int y) {
this.x = x;
this.y = y;
}

public boolean isAlive() {
return true;
}

public boolean isAdjecent(Cell adjecent) {
long diffX = Math.abs(adjecent.getX() – x);
long diffY = Math.abs(adjecent.getY() – y);
return diffX == 1 || diffY == 1;
}

public long getX() {
return x;
}

public long getY() {
return y;
}
}
[/sourcecode]

Wait, stop, halt!

If the above sounds familiar, then I’ve got news: This is not TDD

Lets get back to the original question, what did we try to implement? Ah, it was the question:

“Any live cell with fewer than two live neighbours dies, as if caused by under-population”,

So where is the corresponding test for that?…

In fact, we have already three tests and a bunch of code, and we still are not able to answer the question.

What we’ve done so far is write tests first in order to prove a solution we already had in our minds. We did not let the tests guide us to a design. In fact, we already had a design in our heads and made the tests conform to those.

Lets do it in TDD, for real…

So how is it done ? – Test Driven Development

With a clean slate, we start over. And we start with the first rule:

“Any live cell with fewer than two live neighbours dies, as if caused by under-population”

So we create a test (we call it Test, because we do not think about Cells yet, in fact, we are only thinking about this very question).

[sourcecode language=”java”]
@org.junit.Test
public void anyLiveCellWithFewerThanTwoLiveNeighboursDies() {
int neighbours = 1;
Assert.assertTrue(neighbours < 2);
}

[/sourcecode]

So what does this do, it basically returns true when neighbours is lower than two. We do not call methods yet, we simply have our implementation within the test itself. In this phase, we already had Red (non compiling), Green (compiling and green test). On to refactor. How to get it more descriptive? We could do something like this:

[sourcecode language=”java”]
@org.junit.Test
public void anyLiveCellWithFewerThanTwoLiveNeighboursDies() {
int neighbours = 1;
boolean shouldDie = neighbours < 2;
Assert.assertTrue(shouldDie);
}
[/sourcecode]

Do we need to do anything else? Certainly! But the essential rule is there already. It is one simple statement, no neighbour checking yet. And in fact, we will not need it to implement the four rules! Lets continue. I am serious, we will not modify the above code yet. We have yet to implement the other rules. Lets pick the second:

“Any live cell with two or three live neighbours lives on to the next generation.”

We have actually two cases here, for two and three live neighbours. Lets start with two:

[sourcecode lang=”java”]

@org.junit.Test
public void anyLiveCellWithTwoNeighboursLivesOn() {
int neighbours = 2;
boolean shouldLiveOn = neighbours == 2;
Assert.assertTrue(shouldLiveOn);
}

[/sourcecode]

Not that much different is it? How about we add the third test for the second rule:

[sourcecode lang=”java”]

@org.junit.Test
public void anyLiveCellWithThreeNeighboursLivesOn() {
int neighbours = 3;
boolean shouldLiveOn = neighbours == 3;
Assert.assertTrue(shouldLiveOn);
}

[/sourcecode]

The total test class looks like this now:

[sourcecode language=”java”]
public class Test {

@org.junit.Test
public void anyLiveCellWithOneThanTwoLiveNeighboursDies() {
int neighbours = 1;
boolean shouldDie = neighbours < 2;
Assert.assertTrue(shouldDie);
}

@org.junit.Test
public void anyLiveCellWithTwoNeighboursLivesOn() {
int neighbours = 2;
boolean shouldLiveOn = neighbours == 2;
Assert.assertTrue(shouldLiveOn);
}

@org.junit.Test
public void anyLiveCellWithThreeNeighboursLivesOn() {
int neighbours = 3;
boolean shouldLiveOn = neighbours == 3;
Assert.assertTrue(shouldLiveOn);
}
}
[/sourcecode]

We have done some little TDD cycles already. We started describing the problem domain, and we added the minimum amount of code to make this work. We did not yet start write any production code yet. Now one of the most important steps in TDD should be taken: Refactor. (Remember it is Red – Green – Refactor!)

With the third test, we clearly see duplication. The shouldLiveOn can be extracted to a method. Lets do that:

[sourcecode language=”java”]
import org.junit.Assert;

public class Test {

@org.junit.Test
public void anyLiveCellWithOneThanTwoLiveNeighboursDies() {
int neighbours = 1;
boolean shouldDie = neighbours < 2;
Assert.assertTrue(shouldDie);
}

@org.junit.Test
public void anyLiveCellWithTwoNeighboursLivesOn() {
int neighbours = 2;
Assert.assertTrue(shouldLiveOn(neighbours));
}

@org.junit.Test
public void anyLiveCellWithThreeNeighboursLivesOn() {
int neighbours = 3;
Assert.assertTrue(shouldLiveOn(neighbours));
}

private boolean shouldLiveOn(int neighbours) {
return neighbours == 3 || neighbours == 2;
}
}

[/sourcecode]

We could refactor out the neighbours var to a constant, which should give us even smaller tests.

At this point we have now our first method which could eventually be moved out of the test class into some other class (we have yet to think of a name for). As you can see, the design of our code is being driven by the tests. So this may like trivial and like ‘cheating’. In fact, as I see it we are actually answering the real questions. We tend to write code for stuff we cannot possibly be sure of that it is correct. Did you see any line say that the Game of Life in this situation should be on a 2D grid? What if it would be 3D? What if we did not know yet if it would be 2D or 3D?

This sounds a lot like real-life isn’t it? Where your customer does not always know exactly what he wants.

Another good thing is, we can implement all rules like this. Eventually we end up with a test class that contains several methods. From there on we can think of a logical way to group them. Methods grouped together will form classes. We tend to group methods logically. When we define the problem domain we know better what classes should exist. Again, our tests drive the design. Instead of the other way around.

Here is an impression how the four rules implemented might look like:

[sourcecode language=”java”]
package com.fundynamic.coderetreat;

import org.junit.*;

public class Test {

public static final int StarvationThreshold = 1;
public static final int OverpopulationThreshold = 4;
public static final int MinimumRevivalThreshold = 3;
public static final int MaximumRevivalThreshold = 3;

@org.junit.Test
public void liveCellShouldDieIfLessNeighboursThanStarvationThreshold() {
int amountNeighbours = StarvationThreshold;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void liveCellShouldDieIfNeighboursEqualToStarvationThreshold() {
int amountNeighbours = StarvationThreshold;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void liveCellShouldLiveIfTwoNeighbours() {
int amountNeighbours = StarvationThreshold +1;
Assert.assertEquals(true, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void liveCellShouldLiveIfThreeNeighbours() {
int amountNeighbours = 3;
Assert.assertEquals(true, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void liveCellShouldDieIfFourNeighbours() {
int amountNeighbours = 4;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void liveCellShouldDieIfEightNeighbours() {
int amountNeighbours = 8;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void deadCellShouldReviveIfMinimumRevivalThreshold() {
int amountNeighbours = MinimumRevivalThreshold;
Assert.assertEquals(true, revivesInNextGeneration(amountNeighbours));
}

@org.junit.Test
public void deadCellShouldReviveIfMaximumRevivalThreshold() {
int amountNeighbours = MaximumRevivalThreshold;
Assert.assertEquals(true, revivesInNextGeneration(amountNeighbours));
}

@org.junit.Test
public void deadCellShouldNotReviveIfLessNeighboursThanMinimumRevivalThreshold() {
int amountNeighbours = MinimumRevivalThreshold -1;
Assert.assertEquals(false, revivesInNextGeneration(amountNeighbours));
}

@org.junit.Test
public void deadCellShouldNotReviveIfMoreNeighboursThanMaximumRevivalThreshold() {
int amountNeighbours = MaximumRevivalThreshold +1;
Assert.assertEquals(false, revivesInNextGeneration(amountNeighbours));
}

private boolean livesOnToNextGeneration(int amountNeighbours) {
return amountNeighbours > StarvationThreshold && amountNeighbours < OverpopulationThreshold;
}

private boolean revivesInNextGeneration(int amountNeighbours) {
return amountNeighbours == MinimumRevivalThreshold;
}
}

[/sourcecode]

But you did not even get to any cell? How is this any good?

It is true that cells play a role in the Game of Life eventually. But they do not play a role in answering the four questions. In fact, what are cells? We might be talking about squared cells, but perhaps you want to write your 3d version of it. Or you might want to use hexagons. If you put the rules logic into a cell, it gets very hard to modify your code because you have put too much responsibility in one class.

TDD prevents you from doing this.

Also, if you started with using Cells and the matrix and all that. I would wonder how you would implement the last rule (reviving cells). How would you solve this problem?

Bottom line

Writing tests before your production code is not the same as TDD. It is about how your tests drive your design. Only then you can say if you are doing TDD or actually are just writing tests proving your own solution you have thought about before-hand.

It is hard to not think ahead of your design, and instead trust on our tests to let the design emerge itself. This requires practice. Practicing this can be done in coderetreats for instance.

First coderetreat of 2012 in Amsterdam – Retrospective

At the end of 2011 I started organizing a coderetreat. It started on twitter around October. I’ve also posted about it in my last mini blog. The original event can be found here.

If anyone was interested, they could sign up (max 25 people) for free. All you needed to do was bring your best humor and if possible a laptop with your preferred dev environment set up. (Its not hard to organize one, check here if you’re interested)

If you want to know more about what a coderetreat is, click here. Even better: join a coderetreat somewhere near you and experience it. It is way better than just reading about it 🙂

Honing the craft together

Coderetreat

Lets start with a management summary:

It was awesome!

It reminded me of my experience with the bowling game kata last year. Since you’re repeating the exercise over and over again, you will find different approaches. Even better, because you’re switching pairs, you will have a different mindset literally to approach the problem presented by the coderetreat. Instead of writing a bowling game, you will be working on Conway’s Game Of Life.

The most notable things of that day where:

  • In the very first session we where let ‘free’. We could approach this problem how we wanted. Me and my pair where able to implement the first three rules. However we where not able to implement the fourth rule. Our design was not easy enough to revive dead cells. (gosh, this reminds me of the bowling game code kata first attempt…)
  • The second session we got to choose from different constraints. I picked the “no conditionals” one, because I can get my methods under 4 lines without pain. Programming without no conditions is a whole different story though.
  • The third session with ‘only check in within 2 minutes, else revert everything’ was an eye opener! It really forced you into thinking how to make all (baby) steps. Hence, I am using this at work now and it really works. I commit 10 times more often. Although I don’t make the 2 minute mark yet at work (5 minutes is easy though now).
  • The fourth session was fun, as we where able to implement *all rules* (opposed to the first session), but without the code we had implemented in the first session! We totally isolated the behaviour (this session was called “tdd as if you meant it”) and it blew our minds.

Will I attend more coderetreats? You bet! Just need to take a look at the list of events and pick an appropiate one. If I attend one, I will let you know (on twitter surely, perhaps on this blog).

If you want to know how it looked like, click here to see som pictures of the coderetreat.

I loved the coderetreat, and I’ll surely organize one again in the future. I would recommend anyone who loves his profession to join a coderetreat and practice. You’ll learn new things for sure!

How hard can it be, right? 😉

Retrospective : JFall 2011

I’ve visited JFall, a conference held by the NLJUG (Dutch Java User Group), at 2 november 2011. In this blog I’d like to share my experiences of this conference. This was my first time at this conference and I pretty much had no expectations.

My pass for JFall 2011

There was a lot to go to; I have visited the following seemingly interesting topics:

Keynote – Java 7 Directors Cut
Overthere – Design and implementation of a Java Remote File and Execution framework
Hands on lab – Clojure – A gentle introduction to a brilliant language
Keynote – Building Highly Scalable Java Applications on Windows Azure
Migrating Spring to Java EE 6
Hands on lab – Whats that smell? – Refactor away that nasy odor

Its completely personal
For each topic I will write down my personal experiences. They are by no means complete. In fact they are completely biased. If you also have visited the JFall conference and you feel different about one of the topics; let me know in the comments below.

Keynote – Java 7 Directors Cut
The keynote consisted of two parts: The first part was about Oracle; how they are not that bad and how they had a rough year in 2010. All I was thinking was : “get on with it“. The second part was about Java 7. It took quite some time before Java 7 was released. (yes Java 7 is released already). In this part it was explained why it took so long and how Oracle played a role in getting it released.

Overthere – Design and implementation of a Java Remote File and Execution framework
This one was actually quite interesting. The talk was about a remote execution framework. Roughly said you could connect to a remote machine via this API, and then execute commands there. Its main goal is to make automated deployment easier. What I missed is they “why” part. Why is this framework built in the first place? What kind of trouble was this framework meant to solve primarily?

Hands on lab – Clojure – A gentle introduction to a brilliant language
Although the start of this session was a bit clumsy; it was really hands on. We did a lot of practice stuff, but also here I did not get any answer to why and when I should use Clojure in the first place. Someone asked if it was used within webapplications. But it seems it is not used that much at all within webapps. (is this so?) The language itself is something to get used to, and 50 minutes was really too short for this. It did spark interest a bit. What I found most intriguing is that using Clojure it forces you to think differently about solving problems. I found that very valuable.

Keynote – Building Highly Scalable Java Applications on Windows Azure
Microsoft presenting at a Java conference, who would have thought that? I think this actually was a great way for Microsoft to show how their attitude towards the Java community has changed. And for good reason. There are tons of Java powered (web) applications and Windows Azure is a platform capable of running them.

The keynote was given at a high speed; and it had (very daring) a live demo. Of course something went wrong, but in the end things did work. Also everybody could get a 30 day free trial of Windows Azure. The presentation concentrated about the effort needed to run Java based applications into Windows Azure. Also, it showed what configuration was needed to actually deploy an application. Aside the Java ‘support’ at Windows Azure, some architect schema’s where shown of well known websites (Flickr, Twitter, etc) and the match with Windows Azure was made. (Like: Yes you can do all these things with Windows Azure).

Migrating Spring to Java EE 6
This show starts with a big disclaimer, in the form of 3 slides and lots of talking about that “this presentation is not a shoot out”. I was wondering why, but the reason became clear after a few slides after that. In short, it was all the way “Spring Bashing” all the time. The use-case was that there was an old Spring application (what is old anyway?). And that you somehow must migrate. You have two options:
A) Migrate to a new Spring version.
B) migrate to Java EE 6.

Since we both know the subject of this presentation we are *not* choosing option A. Then the ‘fun’ part begins. The reasons given to use Java EE is mostly “because it is the standard”. I always get the chills of such comments. What is the standard anyway?

Its a pitty, because the reason that Spring is propriety software is actually valid. However, it just won’t cut it when yelling “its the standard“.

Then it begins, the migration path. And guess what the first step is: Update to the latest spring version. The reason is that Spring has a great backwards compatibility. One would wonder why to migrate further away from Spring from that point. Basically migrating to the latest Spring version would be easier, painless and won’t cost your business that much.

Something different that struck me was an example of how Spring is unable to render objects given by a (JDBCTemplate) DAO as you will be presented with a LazyInitializationException. So the solution in Java EE is that you put an anotation that says the bean scope is “Request”. Apart from the fact that Spring can do this too, it is also in my opinion (in Java EE and in Spring) a bad practice. I think that objects returned by DAO’s should *never* be used in the view. They are not the same thing, so don’t even try it. If you do you’re being lazy.

I think the presentation would be much better if the starting point would be an assignment like “build a web application”. Then you could argue if you would need Spring and why not (since it would be about Java EE 6). Then, you could show everybody how Java EE 6 is capable of doing things Spring can do and how much it has been improved. This would probably be much better than bashing into an existing (older) Spring application and telling everybody to migrate just for the sake of standards. I don’t think any customer would be willing to pay that bill.

Hands on lab – Whats that smell? – Refactor away that nasy odor
I love refactoring, so this one was more of a nice way to close the day. To me it was more like a rehearsal and getting the vocabulary right. I actually found that quite a positive side. Too bad it only lasted 50 minutes, which was way too short. The introduction was also a bit too long so the actual development time was not that long.

In overall
It was big. It was busy. It was very nice to experience. Often I wanted more, more in depth, more time. I see that as a good thing :). On the other hand, I think the NLJug should consider to spread JFall over two days. This way people can choose between several sessions, and the sessions given can be longer and allowed to be more in depth. Especially if the program has some repitition in it, I could choose to visit some workshops on day one, and then watch the presentations at day two which I would have missed at day one.

Experiencing a Code Kata – Become a better developer while having fun!

Recently I have been experimenting with a Code Kata, and in this post I’d like to share my experiences with it.

Code Kata?

Code Kata’s have been around for a while, but it really came into my attention while reading Chapter 6 from the book The Clean Coder by Robert C Martin. This chapter makes an anology that at your work you’re a performer like a musician and outside work you (should be, like a musician) practicing. (Of course, you will learn while at work, but that is not the point).

But what is a Kata?

I have played the piano for around 6 years (followed lessons) and played it much less after that (in fact, I don’t really play at all anymore). In those six years I had to practice etudes as well as more famous pieces. I did not understand why I had to practice Etudes, until much later.

So what has an Etude to do with Kata’s? Lets look at the description of an Etude (at wikipedia):

“an instrumental musical composition, most commonly of considerable difficulty, usually designed to provide practice material for perfecting a particular technical skill”

Without going into detail of a Kata itself, it is used to practice and perfect a set of techniques. Repetition and practice until you’re able to perfectly perform a Kata (or an Etude if you will) will help you further when you need to improvise or apply it in different forms. A lot of Etudes, techniques, are used in real pieces. A lot of Code Kata’s are actually dealing with real world problems.

Its not all about the solution!

So if I practice enough code kata’s I will become good at any problem I might face when writing software?

Not quite.

Code Kata’s are flexible; meaning you must set yourself a goal you want to achieve by doing a kata. When doing an etude you don’t have a lot of options. Your main goal is getting better with your fingers to play a series of notes or transitions. With a Code Kata you could practice your typing. Or perhaps practice all short-cuts of your IDE. Or heck, learn a new IDE while doing one. Perhaps you want to learn a new language. Perhaps you want to get better at TDD. Or you simply want to get to the solution and find the most efficient way to do so.

Atleast, I found doing a code kata much more fun than doing an etude 🙂

Bowling Game Kata

The Bowling Game Kata is a Kata that challanges you to write a class (Game) that simulates a bowling ball game. You can roll balls and give the amount of pins knocked down. At the end you can call the score() method and you should get the correct score. It takes all rules into account, gutter, spares, strikes and the tenth frame where you can have 3 rolls instead of 2. The perfect game has 300 points. The worst game 0.

My initial thought: How hard can this be? I mean come on, I’ve dealt with harder things than a bowling game scoring system. Since I did not do any Code Kata before I set my goal to find the solution to this kata while doing TDD. I also did not want to look too much ahead in Uncle Bob’s (very nice) presentation (with solution). So I stopped when the game interface was given (roll() and score()) and I went ahead. Again, how hard could it be?

I have tried this Bowling Game Kata three times, and for each attempt I have written my experiences. All in all it was a very good experience and I recommend to try it out yourself. I believe if you want to get better, you need to practice. And only if you tried this multiple times, only then you know how it is.

So instead of talk the talk, let me walk the talk…

First attempt – Deception

Goal: Get it working, while doing TDD.

I set up a simple project and started with the GameTest. The first two tests where easy to do (0 pins, and all ones). But as soon as I got into Spares my first thought was to create a Frame class. Because a Frame represents a ‘turn’ where you can only roll 2 balls. The Frame class was born, along with its unit test. And I thought it felt good. I even added more ‘cheating’ detection. So you cannot roll 3 balls in one frame, or you cannot say you rolled 2 pins and then 9 (making 11 in one frame). I felt great and got unit tests working like nothing could stop me. Until the ‘perfect game’ test came around and my model just fell apart.

There was no way I could make it fit, without bending my entire model/solution.

So there I was, totally excited and thinking “just one more test and I’m done”.. and I got this.

Eventually I fixed it, I made my Frame class more flexible so I could set the maximum rolls and added flags. I then could create a TenthFrame class and set its flags so it would score differently. I also had created tests for the TenthFrame and even used an Abstract test class so I did not have duplicate code. Even so, I felt like this was wrong. I was bending my design just to work for one exception in the rules.

When I got all my unit tests passing, even the perfect score game, I just felt a great deception. My design sucked. Also, it took me almost 4 to 6 hours to get it working. Way too long for a code kata right?

Lessons learned
– TDD cycles where not strict enough; so…
– TDD cycles where slow, I had to switch mouse/keyboard to rerun the unit test(s)
– I made design decisions too early and later got ‘stuck’ and had to bend the design to make it work completely
– Finding the solution the first time takes time
– I made much more stuff than I had to (over-engineering?)

Trivia
– Time taken: roughly 6 hours.
– Amount of unit tests: 33

Second attempt – No need to bend the universe

Goal: Get it working, while doing TDD. Take lessons learned from first attempt. Aka: Tighter TDD cycles, get faster at TDD cycles, etc.

I started this kata late in the evening. I spent a fraction of the time compared to the first attempt: ~ 45 minutes(!). The later half hour mainly refactoring and keeping green bars. The actual solution was there within an hour. I did not have to bend my design, I could keep everything within the Game class!

Something little, but practical I learned about the IDE I used (Eclipse) is to short-key the ‘rerun last test’, so my TDD cycles where shorter.

I also noticed I understood the scoring of the bowling game much better. I don’t play this game very much, and when I do, the computer does all the scoring for me. So I guess the first attempt at the Kata took also longer because I had to understand the scoring rules.

Design wise I found that I still use “frames”, but not as a separate class. I do not have any cheating detection (so I can roll 12 pins and it won’t complain), but the scoring will utterly fail in that respect. Building these checks in would not be a problem though, because the spare/strike detection is now so easy.

Lessons learned
– Faster TDD cycle by using shortcut for re-running tests
– TDD cycles where stricter, but could be even more tightened
– Commenting out tests when more than one breaks really helps you get focussed on getting one thing to work (so leave one test breaking), instead of fixing all tests at once.
– No cheating detection, no over-engineering
– Of the time consumed, I spent more time refactoring relatively to the first attempt, than thinking / finding the solution.
– I could refactor a lot of code, and make it much more cleaner. And safely due the tests.

Trivia
– Time taken: roughly 45 minutes (!!)
– Amount of unit tests: 7

Third attempt – The only way to go fast is to go well

Goal: Tighten the TDD cycle. Get it done in 30 minutes or less.
This time I started fresh on a Sunday morning. Since I know the solution and I knew the design choices I made earlier (I know what works, and what does not work) things went very quick. I finished it within 30 minutes. I had the same amount of unit tests and the greatest thing was that the last test (perfect game) worked immediately. I did not had to change anything to make it work.

Once I had the last test working, I checked the code a bit and called it done. This time I also wanted to check my solution against the original presentation Uncle Bob made, to see if I missed anything or not. I figured that some of my tests where faulty:

– If you roll only ones, you can only roll 20 times and not 21 times. (i had a weird if statement to fix this up, but now it seemed that this was flawed).
– The perfect game was in my case 21 strikes, while you can only roll 12 times in that case. When I changed my test, it still worked.

It struck me that I was approaching this technically (21 rolls is maximum), and not from a functional point of view (ie 20 is max when only ones).

I also found that my TDD cycles where still to wide. I could do run the cycles close to each line of code, but I tend to write 2 or 3 lines before re-running my tests. Especially the first tests where suffering from this, later tests went better.

Lessons learned
– TDD cycles can be shortened
– Functional point of view caught errors in my tests
– Shortest kata ever (under 30 minutes)
– Latest test worked, design was good. Design was even better after fixing the test for ‘only ones’, so I could remove weird if statements.

Trivia
– Time taken: < 30 minutes
– Amount of unit tests: 5

Retrospective

So, after 3 attempts, do these Code Kata’s work for me? It surely learned me a few lessons. In short:
– The first time you do a Kata, it is slow. And you’re focussed on the solution. This could throw you off, but you have to persist…
– Later attempts are going much faster, and your focus shifts to other techniques. Mine was mainly speeding up my TDD cycle.
– I have learned a few things to speed up my TDD cycle, which I can apply in real world stuff as well. Which is good!
– Over-engineering will bite you, one way or another. Your design will be toast.
– I have learned that even in my last example I was approaching the solution too technical. As a Developer I still did not approach it entirely functionally. This meant that even though I thought I was done, I wasn’t. I do plan to use Acceptance tests (using JBehave) for this. That will be covered in a next blog.
– Above all, doing a Code Kata is fun!

I would advice to other developers to do Code Kata’s and get better at what they are doing. There are tons of areas where you can improve. In short, yes I do believe in them and I think you should give them a go, if you haven’t already!

Find more about Code Kata’s:
http://codekata.pragprog.com/
http://stackoverflow.com/questions/44533/your-favorite-code-kata
http://www.codinghorror.com/blog/2008/06/the-ultimate-code-kata.html

If you really want light-weight warm up exercises, you might want to go to: http://codingbat.com/

My experience with (un)certainty about estimates in relation to technical debt

Not too long ago, Martin Fowler pointed out a nice blog post by Jay Fields. Jay Fields refers to a nice talk he had about accidental complexity and essential complexity and how this has impact on your estimates. He found that not all developers consider the accidental complexity and therefor have lower estimates.

I found this a very interesting thought. It got me thinking how I estimate and how far I’m off. I found that, especially with larger solutions, I’m most of the time under estimating. Even with more complex things, and adding some ‘unforseen complexity percentage’. I’m still under estimating most of the time. However, I’ve also had better experience on other projects. Especially the latest project I’m working on the estimates of fixes and rework are not as much off. How is this possible?

I find myself labeling this phenomenom as “lack of overview”. If you read the definition of Accidental Complexity, it is described as “…accidental complexity is caused by the approach chosen to solve the problem.”. I believe this ‘approach chosen to solve the problem’ is the design of the code. This is different comparing to Essential Complexity, which I belief is much like Cyclomatic Complexity.

I made mistakes with my estimates, even when I knew the code well. Often it was due a dependency that ‘got in the way’, or worse, the lack of dependencies. All functionality was in one class! Adding similar behaviour required me to duplicate code. I consider this a bad practice, so I had to extract code from the other class. I was untangling the code. Whenever I had to untangle that code (ie, seperate concerns), I had a hard time doing so: Because untangling a tangled (tightly coupled) piece of code forced me to untangle other pieces of code as well. I had to stop somewhere. Like someone once said to me: The devil is in the details. (this is one of the reasons I encourage my co-developers to talk to interfaces, and not implementations).

But why are estimates off anyway? Is it because (lack) of experience with the code? Even with code I’ve worked with for years I still made bad estimates. And I could not find a way to get them better. The newer project went way better for me to estimate. I already knew why it was going better:

My mental model of the code matched better to the actual code. Was it because I worked on it lately and knew how it worked exactly in detail? No, not at all! The Technical Debt is much lower on this project. One of the principles that played a huge rule was the Single Responsibility Principle (PDF). When I had to make a change, it was often in one place. When I had to add code, I could easily move code out of the class and seperate responsibilities. The code was less tangled, tightly coupled.

This phenomenom of untangling code, seperating concerns and having a hard time maintaining code is clearly a sign of repaying serious interests of technical debt. And I clearly see that as a result of a ‘choosen approach to solve the problem’.

Therefor I believe the technical debt is linked to essential and accidential complexity and even more (what about readability?). Accidential Complexity is something that is very hard to grasp. I think this ‘uncertainty’ needs to be clarified and be added to each initial estimate in order to get a ‘more realistic’ estimate.

I would recommend to estimate code while looking at the code itself, rather than use just your mental model of the code.
Finally, repaying the interest of the technical debt should be prioritized in order to be able to maintain the system and to prevent to get a mad customer getting ever less features using ever increasing time to make them.