Ah good; free high speed Internet access in my hotel room.

Extreme Programming

One of the things that I thought made Extreme Programming inappropriate for shrinkwrapped software was the fact that XP calls for frequent iterations, which is usually interpreted to mean frequent releases. With shrinkwrapped mass market software, you just can’t do that. Tech support would become completely impossible if some customers were using Windows May 15, 1998 while other customers had Windows May 16th (Second Release), 1998. There are similar problems with embedded software. You really can’t rerelease the embedded software that runs your BMW engine every day or every week.

Talking to Kent Beck about this today, he pointed out that the simple solution is to do frequent iterations but only release on a longer schedule. Thinking more about this, I think we might move to a model at Fog Creek where a select group of volunteer customers receive very frequent releases in exchange for providing very frequent feedback, while the rest of the world gets far less frequent releases. The nice thing about this is that we can design something, implement it, and realize that the design was wrong and then be able to change it without having to maintain backwards compatibility with the old, “wrong” design (CityDesk customers following the whole URL naming convention switcheroo will understand what I’m talking about, here.)

Some other notable Beck quotes: “The fundamental project management question is: we’re halfway through, are we halfway done?”

And on the topic of rolling out XP to a large organization: “It’s not divide and conquer, it’s conquer and divide.” Get your XP teams working right first, then split them and add new people to each half. Building a consistent culture for code development requires that everyone is on the same page. Add people too fast, and you’ll find yourself with lots of different cultures, which creates conflict, inconsistency, and problems at the edges.