Symphonious

We've been switching pairs a lot in an effort to try to share knowledge between team members before and it's been working really well. The downside to it though is that since the team owns the tasks and people swap between tasks so much (which is what gives the shared knowledge), there's always the danger that you will get off track and start wasting time writing code that isn't actually needed for the user story.

That's where acceptance tests should help out. You should be able to sit down to work on a story and decide to work on getting a specific acceptance test to pass. List out the steps required for that acceptance test and then start working on them. If you wind up changing pairs before the acceptance test passes, leave the todo list with whoever picks up the task and they will know where to pick up from. The new pair should still check that the tasks you've listed make progress towards the acceptance test. In true XP style the hand-over is a conversation between the old pair and the new pair explaining what they were doing and why.

None of that of course precludes one person from the old pair staying with the task - indeed it's much better if you only switch out one person from the task at a time, but the hand-over and acceptance tests are still beneficial just as a sanity check to make sure you're on track.

So acceptance tests do more than just tell you when you're done, they also tell you where you're going, where you're up to and what you should do next. We need to get more disciplined and write acceptance tests up front so that we can use them as our roadmap while we work. Get back to the acceptance driven development we had going when we first starting with XP.

In order to write atomic tests for classes I've gotten into the habit of injecting dependencies instead of creating them inside the class. This makes it simple to mock the dependencies but means that those dependencies are now externally visible instead of being neatly encapsulated and it means that somewhere in your code, there has to be a place that actually creates all these instances and passes them in.

I have no idea how to test that bit of code.

This pops up in a couple of places I've been working on lately, firstly the main method of a program. How do you atomically test a main method that by definition has to setup all the different objects and initialize everything. I suppose I could use a factory pattern but it seems like overkill. How are people testing these things?

The other problem area is in creating dialogs. I can separate out all the business logic and atomically test that, I can even use JFCUnit to test the GUI code for accessibility etc, but at some point my business code has to create the dialog and show it - how do I test that? I'd really like to keep my business code with 100% code coverage to avoid the slippery slope of just saying "oh I can't test that" (which we've been sliding down a bit). I do need to make sure my atomic tests run really fast though.

Maybe I just have to live with no atomic tests for that bit of my code and leave the testing to integration tests but it opens up a whole in our TDD atomic test coverage which I'd like to avoid if I can.

Has anyone found a way to play with class loaders so that a call to new MyObject() actually creates a mock object/stub instead? Is that so ridiculously complex to do that you'd have no confidence in the resulting tests anyway?

If you want to reap the benefits of pairing in terms of sharing knowledge around your team, you need to make sure you change pair regularly. We've been working on the basis that one pair works on a story until it's done - mostly because we only have a small number of engineers and a large number of projects that we need to work on.

The problem is, we're not sharing knowledge enough. Instead of one person knowing about that new section of code, now two do, but the rest of the team still doesn't so we tend to want to get one or both of those two to fix any issues that come up or add any improvements. It's not a team ownership thing anymore, it's a pair ownership.

So we've managed to get three of us to start pairing regularly and most importantly, rotating pairs at least every half a day. We've only been trying it for a day and a bit so it's too early to say exactly how much impact it has, but I already feel like I have more of an idea of what the other two have been doing the past couple of weeks. We've also discovered a potential problematic area where different approaches could be used, so we know to pay attention to how it goes and work out which approach is better.

For just over a day of interrupted work, that's a pretty positive outcome so far. It will be interesting to see how it progresses and how we can pull the other members of the team into the pairing pool and still cover all the different things we need to work on.

We've begun testing out Hamachi at work as a substitute for our defunct VPN and it's showing a lot of promise. It sets up a peer-to-peer VPN which is quite clever and simple to get working. When combined with installing Bonjour on the Windows boxes (Macs have it pre-installed) and tweaking the DNS settings to add .local to the search domains, the DNS look-up works brilliantly cross-platform as well.

I've now got access to all the important stuff from work to tinker with my little side-projects while still being able to store them in the work subversion repository so others can join in if they want. It's an awful lot simpler to work with than the old VPN stuff too.

The only problem I've seen is every so often some of the peers in the network fail to be connected to and it doesn't ever seem to retry.  Since you mostly only need to connect to the servers instead of everyone who happens to be using Hamachi to VPN in, it usually doesn't matter but it does make me wonder about the reliability.

The Rabbit Hole: Smooth JList Target Animation

There's a JTree animation in the next post too. Cool, but the code is awful so it's probably better to just reimplement the generic technique.