A while back Ben Hyde wrote his thoughts on the key XP principles in What every you doing, it’s wrong! I’m not sure I fully comprehend exactly what Ben is trying to say but a lot of it seems opposed to the way I see XP in theory and to the experience I’ve had in implementing XP.

I’ll start with Ben’s rewording of the summary of Extreme Programming (see also James Mead’s original):

I realized today that I hadn’t made explicit the difference in my mind between features and stories and it’s an important difference. Essentially, a feature is a group of stories that are related and deliver a package of functionality that end users would generally expect to get all at once. For instance, inline table resizing is a feature (note: this is the ability to drag to resize tables, rows and columns – try it in Word). In the first pass, you’d probably have a single story for inline resizing of tables, but it would be too big to estimate. So you break it down into three stories, resize columns, resize rows and resize the table itself.

XP has the concept of keeping the code base in a state that you can ship at any time. That seems like a good idea as it allows you to quickly ship a new version to preempt a competitor’s release or when marketing suddenly wants to attend a trade show and have something new to talk about. In other words, allow the business requirements to drive the release schedule instead of it being purely driven by the engineering team’s schedule.

Pages created on .Mac however are the source of a never-ending headache. Indeed, whenever one requests a page on an account that no longer exists (such as the former .Mac FJZone account), the Apple servers dutifully serve a tri-lingual error page… all the while returning a “200 Found” code. In other words, as far as robots are concerned, .Mac pages live forever.

— Francois Joseph de Kermadec

This has to be my single most hated server misconfiguration. The problem is much more serious than unwanted pages turning up in Google searches – any program that tries to download resources from the server without explicit user interaction gets bitten because the server delivers a 404 page instead of the expected file without warning. The client side program can then only assume the file is corrupt on the server and give up.

I stumbled across the article This Is What You See, This Is What You Get the other day and it points out a number of common pitfalls for HTML editors that have relatively simple solutions, as well as repeating a number of common misconceptions about WYSIWYG editors – primarily that Word or Outlook should be considered good examples of how to do it.

Perhaps an obvious point. At least, the web is not WYSIWIG. What you see on your browser is almost certainly not what I see on mine due to many factors. Differing font sets, typographic capabilities of the OS, use of subpixel rendering, browser rendering engine/version, user display preferences such as screen resolution/depth, display gamma, as so on.

We’ve adopted a point based estimating system as part of rolling out XP, with 1 point being simple, 2 moderate, 3 difficult and 5 meaning too hard to estimate (either too big or too technically difficult). One large feature for the next release has been plagued with 5 ratings, both because the feature is big and hard to break down and because it’s technically very difficult so we’re not always sure parts are possible, let alone how long they’ll take.

A while back I commented that I should look into the Delta Web project – I’m doing some work in this area now but nothing more seems to have happened. The mock schema for tracking deltas only works on an element level so is useless for describing changes to XHTML documents which is a shame.

Anyone know of any further progress or other related projects in this area?

Oops, forgot the direct link to the Delta Web proposal by Andy Roberts.

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.

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.

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.

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