This week I participated in a project launch where we used the practices of the much-touted Extreme Programming. This was a four day event that's just a "kickoff" for a 90 day project. It started every morning at 0730 and lasted until approximately 2030 each night.
The good points:
The Bad Points:
I feel your pain about VSS, especially long distance. It's designed to be used on a LAN: very, very chatty. I think there's a product available to help out with this, but unfortunately I don't remember the name.
To me, one of the most attractive things about XP is the constant refactoring. And not just "problem" code either: everything. If you come across code that "smells" then you fix it, right then and there. You don't need to request time to do it, put it in a queue of other fixes that will never get looked at. Just take care of it. IME that's tougher to get implemented than it sounds, since most folks are all about getting things done right now, measuring productivity in shortsighted ways, etc. That's where the courage comes in...
Extreme Programmers work 40-hour weeks. It's a basic tenet of the faith.It started every morning at 0730 and lasted until approximately 2030 each night.
Occasional overtime is periodically required; two consecutive weeks of overtime should be avoided at all costs, and continual use of overtime is a sign that there's Something Very Wrong Going On(tm).
You want high bandwidth across the customer and programmers. There is no higher bandwidth than working face to face. Every minute you spend composing an email or writing a document is 55 seconds more than would be required to sketch a few lines on a whiteboard/napkin and say "Hey Joe, is this the way the code is supposed to work?"Why this stuff can't get done through email, phone, IM, etc is beyond me, but this seemed to work very well.
There's an old saw about programming that you can only learn one or two new tools at a time. (Why do you think UNIX puts The Fear into newbies?) More than two, and you're setting yourself up for failure, or at least a whole mess of unnecessary headaches and pain.The toolset - since our company drank the.NET cool-aid, we had to use Microsoft's Visual Studio .NET and, specifically, C# and Visual SourceSafe for version control.
The XP way? Whenever you're about to delve into the unknown, schedule a sprint. Pick an unknown (C#, VSS, or VS.NET) and play with it until you're at least a little comfortable with it. Repeat until you can make an accurate prediction on how long it is going to take you to perform Task X with New Technology Y. Time used for sprints is budgeted outside the overall schedule (time out-of-band).
Extreme Programmers own their environment. Period.We lost a *lot* of time dicking around with version control the first day because our source control server was 1000 miles away (we got a local one set up the next day).
The XP Manifesto talks about little things like setting up desks so that two people can sit in front of one keyboard. If you cannot make that simple change to your physical environment (translation: mgmt. doesn't support you enough to tear down the cubes), then you're not Extreme Programmers (and you don't really have mgmt. support, a fundemental requirement).
This also extends to real issues like the build environment. If you read between the lines, you see that XP is a set of mutually reinforcing practices to reduce the overall friction of development. Friction is reduced by removing those annoying little burrs that eat away at your skin, not by cramming more hours in the day (so you move the same distance, accounting for time spent bandaging your skin).
So if you can't get mgmt. support to get a faster source code control server (a really fundemental requirement) or a dedicated machine that can build and test the entire project quickly (fifteen minutes, or about as long as it takes to get a cup of coffee), then you're not using Extreme Programming. XP requires buy-in from the mgmt. and the customer to speed the development process. Anything less, and you're just throwing around this week's fashionable buzzwords.
See the first point. If you're not fresh, then you're not working at peak efficency. XP is intense only because it allows you to structure the project so that you remove all unnecessary distractions and time wasters. There is no greater time waster than being tired.Long hours
Code is never "completed" in the traditional sense.Remaining questions - how often do you get to go back and tweak code that has been "completed"?
Each iteration, you need to do the Simiplest Thing That Can Possibly Work. Customer requirements will vary over time; this week's goal is to implement only those features that the customer wants this week, and implement them as simply as possible. Next week the customer may want a few new features added, and you'll need to refactor what you "completed" last week.
This is why «A day without refactoring is like a day without sunshine».
The good news is that all of this is covered in the XP Manifesto: Extreme Programming Explained, the only book you really need to read and understand to get started.
