At least in my mind, there seems to be a clash of aims in XP. You want to make sure that you have complete confidence in your tests so that you can go faster and reduce the cost of change. To achieve this you write lots and lots of tests – until your fear of something breaking turns to boredom from writing tests you know will pass. Most of those tests are atomic and test a particular component, but fear lies in the gaps between components too so you regularly get recommendations like Ola Ellnestam’s on my previous post, Testing Your Setup Code:

I’ve had an interesting experience the last couple of days – I’ve been trying to add some major new functionality into our list code. The code is exceptionally well tested and fairly easy to understand but it wasn’t clear how to write a test that described the functionality I wanted to add.

I started off by writing an acceptance test for what I wanted and then started drilling down to what I needed, but it was leading me off into a rewrite of our list code because it was too difficult to see how to reuse the existing code for what I wanted. In the end, I decided to almost reverse refactor the existing code to extract out the logic that I needed. I say reverse refactor because instead of making the code simpler to read and understand, it was making it more complex – it really felt quite wrong to be applying the refactorings.

I complained before about Obnoxious Referrer Links and now Andy has stumbled across problems they cause in the real world.

It turns out that having a meme tracker for the feeds you subscribe to can produce some interesting results. The big issue is that some feeds either rewrite URLs to include a redirect through their server, or strip all HTML and just give you a snippet of the article. This makes it basically impossible to determine if two items link to the same article.

A lot of projects these days have taken to using a wiki as a way to get the community to write the documentation for them. This appears to work really well with a huge range of pages being created telling you how to do all kinds of stuff. Unfortunately, for anyone who actually needs to learn about the project, these pages are about as useful as tits on a charging bull.

Why is it that a hugely database dependent framework, that’s meant to be extremely quick to get up and running with is so infuriating when it comes to get it actually talking to the database? I know cross-language interfaces are always difficult, particularly when you try to make them work cross platform but if I can get Java, PHP and perl all talking to MySQL easily, why does it have to be so damn hard for ruby?

I realized an unintentional side effect of deciding to not use the ternary if (a ? b : c) – there’s a bunch of code that we don’t duplicate that we otherwise probably would have. In particular, when working with views there’s a very common pattern to convert between a Shape and a Rectangle1:

Rectangle bounds = shape instanceof Rectange ? (Rectangle)shape : shape.getBounds();

The reason for this is that getBounds() on a Rectangle will create a new Rectangle instance so if you happen to be getting the bounds a few thousand times every time you go to paint the text pane, you generate an awful lot of useless rectangles. Since every shape passed in is in fact a Rectangle, you can eliminate all of that junk without risking a ClassCastException if at some point you do get a different type of shape.

Once you have an automated build, the next step is to automate deployment1. A lot of people take this to mean that you should be able to check out the code, compile it and deploy it all from your local work station. I think this is largely a really bad idea.

Firstly, if you have deployment system that needs to vary, or might in the future need to vary, based on the version of the product, then your deployment scripts have to be in source control with the product and be branched and versioned just like the actual source code. If your product just spits out a zip file that is uploaded to a web server for clients to download, you my want to separate the deployment of that zip file from the code base since it will change based on changes to the web server, not changes to the code. You should however still be able to build the zip file from scripts that are versioned with your source code.

Having a fast build is an important part of XP so that the continuous integration cycle doesn’t take too long. Do people usually see this as including all the acceptance tests as well or does this just include the developer’s tests?

How do people handle acceptance tests failing? Does it cause the build to fail or not? What about acceptance tests that have been added for the current iteration but haven’t been implemented yet?

There’s a lot of talk about how you convert a legacy project over to TDD, and there’s a lot of talk about how you TDD on little code examples, but how do you get started on a real project? For a swing app, how do you TDD public static void main(String[] args)?

Atomic testing wants you to be able to mock out your dependencies, which leads to things like dependency injection. Somewhere along the line though, someone has to create those objects and pass them in. How do you atomically test that?

In James Shore’s chapter on Continuous Integration for his upcoming book, he strongly recommends using synchronous integration, where each time you check in you stop and wait for two builds to complete before moving on, in favor of asynchronous integration, where you check in and move on to your next task leaving an automated build server to check everything’s still okay. The whole point of continuous integration is that your team integrates regularly, so that you avoid conflicts. I can’t see how this is encouraged by adding up to twenty minutes of work1 every time you want to check in.

Recently there was a security flaw introduced by a security patch for IE, this obviously is a really bad thing and something the IE team1 have received a lot of criticism about for some time. Obviously, the IE team took it seriously and tried to find ways to make sure it didn’t happen again. One thing that really bothered me though was a statement in the IEBlog:

In parallel with making the right fix, we have been working through how we prevent similar mistakes from happening again. For instance, we have code-reviewed the past ten months of code check-ins from the developer responsible for this issue.

I’m glad Andy side-tracked into talking about us temporarily dropping pair programming – I’ve been considering the same kind of things but want to see what the rest of the team thinks about it before I say too much.

Slightly off topic, the development speed we’re achieving now is making me wonder if the tradeoffs when developing purely under Pair Programming are actually worth it.

There’s a lot more that has changed recently that has led to our sudden improvement in velocity – not just pair programming. For a start, we’re more focussed on the task because we’re not sharing the support load around the entire team. Plus, the business has really started to understand how difficult it will be for us to get things done so they’ve gotten off our backs about everything else and really focussed on hitting this big scary deadline. We were splitting our development efforts between two or three products and the context switching was killing us.