In several occasions, eXtreme Programming (XP) has received criticism for not being sufficiently scalable when applied by growing in size teams. Having worked on a few large - 20+ strong teams - projects, I can testify that delivery targets did not suffer one cent.

What, in my opinion, receives a slight hit, as a team’s size grows, is code quality. Now, that’s not the type of code quality that will noticeably, if at all, affect the end product the way the End User perceives it. It is a developer’s code quality I’m talking about. It’s about the perfect architecture and coding practices and elegant code, efficient solutions and patterns. The kind of code that makes you want to find a pen and put your signature on it, because it makes you feel proud.

I don’t think this is an XP-specific observation, it applies to all projects in which a large number of developers work on the same codebase, more so on XP, what with XP being people-centric and everything, you know the song.

So what do you do to guard the codebase from wandering off down the nasty path?

Unfortunately, 44.9995% of us developers fall on the bellow-average category. That’s not a statistic I came up with, by the way. I read it in a report which I fail to reference at the moment, but it looked serious enough… And it kind of makes sense. Even when someone comes up with The Absolute Paradigm, it is naive to assume every other member of the team will understand it, much less apply it.

As a team grows, I believe the development environment should adopt a somewhat more autarchic flavor.

Pair Programming and Code Reviews can be very helpful, but , in my experience, cannot sufficiently protect the codebase from slipping into Wild West territories.

For projects that need to operate in time critical situations, the - otherwise fine - restriction-free XP approach should be a little bit constrained. If there is not enough time or resources to bring everyone up-to-speed, up-to-speed should be enforced with Alarms that would ideally start screaming and shouting when somebody doesn’t do the right thing.

These are Alarms in the form of Unit, but mostly Functional Tests that will fail a build in case certain guidelines are not followed when coders check in their latest effort.

Most projects will make use of at least two full blown application frameworks these days. This involves tones of configuration and makes for an area where Build Alarms are particularly well suited for. A build should not have to suffer Logging switched to DEBUG mode, or configurations that have Hibernate spiting the SQL on the Standard Out should not be commited. A few neatly orchestrated Test Cases should be enough to leverage such situations.

CheckStyle can be useful, but it is rather restricted, although, with a bit of effort, can turn into a rather useful tool, especially if superficial rules are ignored and focus is given on more design focused concerns.

If you dread over-assuming non-type-safe Collections, a Build Alarm should go off when it encounters a public Interface’s method that’s not returning a strongly typed Array. If you’re not lucky enough to be coding in an environment that supports Generics, that is.

(I am deliberately leaving out the comparison of Java with other languages here, in order to avoid distracting attention from the theme of the conversation…)

I always try to remind myself and peers that TDD is not an option. TDD is something you just do. If a build breaks from day one when Test Coverage is not sufficient, the amount of confidence on the codebase acquired as the project matures is something that makes a whole world of difference.

TDD must become not second, but First Nature.

It’s like learning how to play guitar with a good instructor. They will insist on you holding those bar chords the right way early on. Fingers might hurt at first, but two weeks down the line you’re doing everything the right way. You learn faster and you play better. And bend a lot easier, too.

Such exercises might seem slightly painful, if not somewhat embarrassing at first, but everyone will end up much the wiser a few months, if not weeks into the project.

Wax on, wax off… Daniel Larusso didn’t win that tournament in one day, you know…

This entry was posted on Sunday, August 20th, 2006 at 9:42 pm and is filed under Software. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.