I have decided to experiment a bit with the planning aspects of Extreme Programming. I will do this as a one man project, at least initially, so I can explore at my own pace, the mechanics of the planning game and those of the practices that I can manage to use on my own.

I am going to develop an instant messaging application. This is a fairly simple concept, but it is a real world application that I believe will present some challenges.

I will keep the iteration length really short, perhaps one or two days. This way I won’t get bored, and perhaps it is possible to turn this into a one or two day workshop if I can manage to compress the process even more.

I do think that using low-tech tools like a whiteboard and index cards is the best way to get a dynamic working environment in a co-located team. In this case though, I am going to use a tool, XPlanner, to help me with the planning for the following reasons:

• I am doing this from home and I think I will get one or two complaints about the mess if my better half sees a room full of sticky notes.

• Having kids around makes the risk of losing user stories sky rocket.

• At the company I work for, we are located across the world. So, co-located teams are at times not an option.

• I imagine extracting data from a tool like this makes it easier to publish how things are progressing on this blog.

I have just installed XPlanner. I am currently wearing my customer hat and am creating the first user stories, trying to really forget that somewhere deep down I am a developer.

More to come.

A while back I got the opportunity to do some coding together with a colleague of mine that works in North Andover. I am situated in Malmö, Sweden, myself so we had a time difference of six hours to overcome. Using tools like NUnit and FIT/Fitnesse we were able to get quite a good flow even if the circumstances under which we had to work were far from optimal.

A somewhat idealized day could look something like this for me:

When I got in to work I got the latest source, built it, and ran the suite of acceptance tests that we had created earlier. By doing that I got a really good overview of what had happened while I was away from the office. The currently failing acceptance test would act as a marker that showed me how far we were into development. I could also quite easily see the progress since the last day. What new tests were passing that weren’t passing yesterday? Were there any changes to the acceptance tests themselves because my colleague had found some changes in the way things ought to work?

When I had reviewed the changes to the acceptance tests, I could take a look at the NUnit tests that had been added or modified during the night. This gave me a good view of what classes had been modified, and in what way. The unit tests acted very well as more low level documentation on what behavior had been worked on during the night. Now I could do a review of the changes made and see if I could see some refactorings that would make things a bit easier to read and make changes to.

Next, I would turn to the currently failing acceptance test. By starting to look at the code that performed the actual test, I could quite easily get a feel for what needed to be done next - make the acceptance test go a little bit further. I could now go on and start developing the next step, using TDD, and hopefully I could make a complete acceptance test pass.

Around 3 pm CET, my colleague would get to work and we could talk a bit on the phone, or using mail, or IM. During this time we could have a quick design session or discuss some other issues that had come up. After that I could go home, and my colleague could take over for the night.

What struck me when doing this was how much communication the tests were able to facilitate, both the acceptance tests and the unit tests. When the other means of communication where crippled, the tests could make up for a lot more than I had expected.

The acceptance tests:

• Provided a progress bar of sorts on how we were doing.
• Gave enough details on what had been done so one could get a quick overview of what had been done since last time.
• Gave a starting point for today’s work. Start implementing the currently failing feature.

The unit tests:

• Provided the details on what had been done since last.
• Provided low level documentation on any new classes that had been created since last.

When most other forms of communication were limited, it dawned on me how much about communication testing really is. Yes, testing is about asserting that your code behaves properly. Yes, TDD is very much a way to get a good, loosely coupled design. But it is also very much about communication. It is therefore important to keep the tests readable and to the point.

I would also like to get the opportunity to try out some long distance pair programming at some point as well, and see how that goes.

I saw an interesting news report on Swedish TV tonight. Kids in the first grade learn to read by pairing up and writing stories for each other using a computer. It seems that writing is easier to learn than reading. Handwriting, however, is too hard for children to start with, and by using a computer they don’t need to focus on the complicated act of forming letters. That can come later.

I see similarities between this and the agile approaches to software development:

• The creative ordering of what to learn first can be compared to how user stories can be switched around as they are considered independent of each other.
• Starting with the simplest thing first. At first one thinks that one has to be able to read before one can write, but as writing according to this theory is simpler for the children; move that first. This can be compared to the idea about “doing the simplest thing that can possibly work” in XP. In some of the more traditional approaches you almost automatically design bottom up, e.g. starting to design database schemas and protocols because that stuff “just has to be in place first.”
• The children wrote in pairs, seated at one computer, one child writing a story to the other. That’s pair programming for you.
• The children had a lot more fun producing stories, complete with illustrations, than they would have had if they had used the more traditional approach.

A writeup of the news report (in swedish) can be found here.
After some googling, I found out that the method was developed by Arne Trageton.

The articles about Managed DirectX are almost two years old now. They are targetting an old version of the SDK, and may not be valid at all in the latest releases.

I will keep them anyway since people still seem to use them, but I don’t plan to update them or write any more.

The mantra of TDD goes “Red, Green, Refactor!” That is, you write a test that fails, you make that test pass, and then you refactor to remove duplication and other code smells.

It’s a good idea to keep in mind where in the TDD groove one is at each moment, even if the time spent in each phase may be as short as a few seconds. When one has a failing test, one shouldn’t be refactoring. When one is refactoring, one shouldn’t write new tests that fail. This is a good rule to follow, and I always try to follow it meticulously.

One refactoring always make me kind of lost when trying to adhere to the above rule: Extract Class. Most refactorings only touch the internals of whatever class is currently being TDD’ed. Refactorings don’t change the behavior of a class, and should therefore not need new tests. In one sense this is true for Extract Class as well; it does not change the behavior of the original class. But it does, however, create a new class, with it’s own behavior that needs to be tested.

The common way to handle this seems to be to just let things be and let the tests that assert the behavior of the original class indirectly test the behavior of the extracted class. In most scenarios this is probably ok, but the fact that you cannot remove the dependency from the original class to the extracted class without losing test coverage kind of bugs me.

After some discussions about this on the TDD list some embryos for best practices emerged.

• When one is using the original tests to assert the behavior of the extracted class, it may be a good thing to make the extracted class a nested private class of the original class. At least as an intermediate step. This tells the world that the marriage between the two behaviors has not been completely dissolved yet.
• As part of extracting the class, take time to consider what the behavior is that one is pulling out of the original class. Then, look for tests that cover that behavior, and see if it is possible to pull those tests out to a different test fixture. Perhaps after some further refactoring of the tests. Initially, let the new test fixture test the original class. After the refactoring is performed, let it test the extracted class.
• Carl Manaster suggested that triangulation be used when extracting the class. I think this can be used as part of refactoring the tests as well.