Yes, we have no XP practices

I joined a team to help them get from a death march project to a demonstrable product. Not being asked to be an XP coach, I’ve been interested to see which XP practices find their way into a team, which are already in place and which are resisted.

Pair Programming : we do some, we enjoy it when we do because we learn so much. We just don’t think it’s necessary for most of the time. That’s the collective “we” – I’d want to use it much more.

Collective Code Ownership : give it time. Currently most of the code “belongs” to P-J (who left months before I arrived) or Nick (who left a week after I started).

Coding Standards : I’m the problem here, because I can’t see the reason for some of the standards used. Blank line between every line of code? A variable of MyCleverDerivedClass is usually myCleverDerivedClass which makes typing much slower. Is it an XP practice to sneak in new conventions to new code, hoping they gain traction over time? I don’t see why not.

Refactoring : I never do this mercilessly, so the issue is whether we do it at all. Yes, some. But I have had a programmer argue that taking out some code from a big class to a small helper class is making it more complicated. I wonder if he’s changing his view.

Automated Testing : not enough, never enough. I use test-driven development for new code, but I haven’t written the coding structures to make the tests either fast or reliable. There’s plenty of testing effort, mainly comparing the new system with the one it’s replacing. Is that a valid alternative?

On-site Customer : pretty good, because the company both use the system and sell it to others to use. So there are team members who really know what it does and have a benchmark in the old system. I’m happy with this; I wonder if the other programmers are.

Short Iterations : pretty good, again, because we want to support the on-site customer in their work and their testing.

Planning Game : didn’t happen in my time - I arrived to a project with defined tasks. However there’s been some low-level action on this, encouraging people to think outside the bug list, consider the value involved in different changes and so on.

Continuous Integration : if God didn’t want us to do this, he wouldn’t have given us Subversion. Admittedly, no-one knows how to add me to the list of people who get the build-broken automatic email. But we’re all checking out the code regularly, so I hear soon enough.

Metaphor : no we don’t – do you? I tried once, but everyone insisted that LongClassNameExplainingWhatItsDerivedFrom is a good practice. In protest I’ve started calling a colleague “Secundus” because that’s a more descriptive name than “Sam”.

Simple Design : not a lot. Too many programmers love complexity, and telling them “you’re not going to need it” gets a response ending in “off”. The only place I’m winning is over next-release features to help with the sales process. There isn’t time to program these “properly” so I’m being allowed to do a quick simple design and then see what emerges.

Forty-hour Week : in place, widely observed. Well, this is the old style City of London.