Bob Carpenter writes the following regarding Extreme Programming, focusing specifically on some of my struggles in statistical computing:

Well, it’s a bit extreme. I think you’ll find better overall advice in Hunt and Thomas’s Pragmatic Programmer without all the silver bullet rhetoric. I wouldn’t bother with the Agile development stuff, but that’s the currently trendy descendant of this whole line of thinking.

Having said that, there are several good take-away messages from the Extreme Programming (XP) process, but I don’t believe, as its proponents do, that you need to do everything their way.

I love pair programming — it’s not only a great way to learn for a novice/expert or expert/expert pair, it’s a great way to keep quality high by keeping each other honest and it’s a great way to catch bugs early on. But if you follow the XP advice to the letter, that’s the only way you’d program, which is impractical in most groups.

You should start using unit testing, which I believed your group referred to as a “self-cleaning oven” (though don’t keep the tests in the same file as the code).

Research coding is both good and bad for XP. The specifications tend to move around even more than in the usual XP project, because you don’t even know if what you’re trying to do is possible before you start much of the time.

And you definitely need version control, which Masanao and Yu-Sung set up for you through RForge.

With some R and BUGS under my belt, I really wish it was easier to stick to the don’t repeat yourself (DRY) principles. All of the R code I’ve seen could use much more modularity.

Finally, you should get into refactoring; it’s really what you’re trying to do with BayesGLM, though it may be easier to refactor GLM first if you’re going to start from scratch.