On Tue, 21 Jan 2003, Adam Fields wrote: > > OO languages are orthogonal to good design... they help, but are neither > > necessary nor sufficient. > > Well, okay, I should have phrased that differently. XP does is heavily > dependent on OO design concepts, whether implemented in an OO language > or not. Taking advantage of that structure in procedural PHP or perl > is a skill most programmers don't have.
Well said. I'd claim this skill is uncommon regardless of language however. I've witnessed even experienced programmers fluent in Java having difficulty adapting to the XP design mantra. > > True, but what process doesn't? > > There are many processes that don't. With XP, your requirements are > your stories, and your documentation is your code. It's extremely > difficult, and possibly not worth the effort, to make an XP project > interoperate with external forces, because of the total lack of > visibility you have into the inner workings of the project unless > you're also doing XP. There are ways of buffering XP to (for instance) a customer who doesn't participate in the process. But if you're talking about development teams, where proximity and communication are critical to XP, I agree. As far as willingness to participate goes, I can see that pair programming creates a network effect in which team members influence each other's involvement and those who don't follow become obvious. There's simply no way to hide behind the process. That's not to say there aren't places where XP cannot work. But I've come to suspect there are fewer than I first thought, and XP may in fact be more widely applicable than common wisdom would have us believe. -- Jeff Sturm [EMAIL PROTECTED] -- http://cms-list.org/ more signal, less noise.
