Extreme Development

Extreme Development (XD) -- It's about Programmers

The driving concern is being able to grow an XP shop more quickly. The answer is to make the programmer the focus, not the code.

XD is likely not as widely applicable as XP, but there are times when building a team is more important than the product being worked on.

XD is most applicable anytime a product must be understood by a wider group. Frameworks, middleware, XML portals and extensible software in general all seem to qualify.

XD should still be 100% XP. We're just adding a few things:

1. Data-centric programming. The overall architecture is an XML file. Less meta data is buried in the code but instead is abstracted into visible structures.

This facilitates both understanding and substantial re-architecting the overall project. Indeed, each application may have its own architecture. (Think of it as allowing for rapid refactoring on a grand scale.)

2. Extensive use of components rather than OO, i.e. compositional programming. Coupling is greatly reduced and generally the need for refactoring is less, or at least spans a smaller portion of the project.

This is the enabler of data-centric programming. But it also significantly decouples our classes. With less coupling to manage, we can now focus more on making it all easier to learn.

3. Open Source Software. This gives us a pressing need to keep our code readable and easy to learn. Team members aren't the only ones reading the code.

We are using XD in a new development center in Raipur. Our first XD project was JxUnit. (A tool for document-centric testing.)

Our next project is actually an existing one--JxQuick. One of the problems is missing documentation for novice users. (The previous version of Quick included extensive documentation.) Documentation could take many forms, but we found a nice XD answer: focus on the needs of our next new-hire. This gives us a deadline (2 weeks), a target audience, and a means of evaluating our work.

--BillLaForge

Interestingly, the description of XD says that it's about programmers, but the examples are all technological solutions.

My coop student had a good observation about XP. He said that he felt XP was less a methodology than a discipline. By that, he meant that it requires a fair amount of skill and experience to pull off. One has to adhere to its principles rigorously without being pedantic about following any particular method.

The question arises, how does one build a team that is capable of being successful at XP? The issues I see as a problem are:

1. How do you build a group dynamic that is tolerant of change? XP requires a frightening amount of code churn. How can the team allay fears in its less experienced staff?

2. How do you teach people how to refactor code? Pair programming helps, but my guess is that intelligently selecting pairs will make a big difference. Are there other techniques for improving this skill?

3. How do you deal with fragile egos? Many people will feel very threatened when their code is refactored mercilessly. This can lead to intimidation tactics and other anti-social behaviour. How do you transition a team where not so good experienced people are used to calling the shots?