When Is Xp Not Appropriate
When Is Xp Not AppropriateIt's worth asking of any approach to software development "When is it not appropriate?" A reasonable answer can improve the credibility of the approach as well as helping people who, maybe unwittingly, are trying to pioneer the approach in a new area -- at least they should go into it expecting to have to solve basic problems or adapt the approach to suit.
The XP pages on this wiki may give the false impression that full XP is equally applicable to all kinds of software in all kinds of environments. Clearly that isn't true, so it would help to define what's not in the scope of full XP! The following list of examples may help lead us towards some general principles:
Unit Testing
Does anyone have any experience that says Extreme Programming does not work in these situations? I agree there are probably situations where Extreme Programming may not work, but it provides no value to just speculate. Real experiences, please.
[A real experience of the impracticality of relying on unit testing, and the ensuing discussion, was factored out into scenario 3 in UnUnitTestableUnits.]
Much of this page [before it was refactored] seems to be about whether UnitTests in the strict sense can find a certain class of defect. IMO they cannot. This, however, isn't much of an argument against using XP. You'd still want as many UnitTests as you could have, because they give confidence and mobility. You'd also need to do something else to be sure your code worked. So, quelle surprise, we need to adjust the process to our situation. Carry on.
Agreed, but I think full XP would require UnitTests to give you enough confidence to do refactoring whenever you think it is necessary. -- GlynNormington
Alternatives to XP
For all these proposed scenarios, what's the alternative?
My experience is mainly in middleware, but using CRC cards at the component level to get a good split of responsibilities and then paying a great deal of attention to inter-component interfaces before moving on to implementation seems to work. In that environment, there is no substitute for understanding prior to coding. -- GlynNormington
Subsetting XP
What this has also done is make me wonder about some of the assumptions here (and in the testing parts of XP as well). Lots of people have said that XP is "all or nothing", while at the same time saying that there are parts of XP that you can adopt (as Glyn suggests) without adopting all of it. I'm wondering what the CoreXpDependencies are. -- KyleBrown
The promoters of cleanroom software development used to say that they didn't understand why, but you had to use all the elements of the method or it didn't work very well, but they didn't understand why all the elements were necessary. My suspicion is that the teams that were willing to take on the whole thing were a bit braver and more resourceful than the average and it was the people who made the difference. I have observed a similar effect in the adoption of formal methods in general. Could the same be true of XP? Perhaps it acts as a filter and the only people who embrace it fully are pretty talented. (Now which XPer's could possibly disagree with that? ;-) -- GlynNormington
Actually, that was the kernel of an early critique of XP by Kendall Scott and Doug Rosenberg. They claimed (in a rather mean-spirited way, and without using much logic) that the same results as XP could be gained by employing a process they called (I'm translating loosely) "Use Smart People". (Someone may have the reference...) -- KyleBrown
Improving one's process is a matter of wisdom, not talent. I'm a living example that talent and wisdom don't necessarily come in the same package. --RonJeffries
[moved from HowMuchDoYouLearnInSchool]
I often see XP mentioned as if it were appropriate for all types of software development. I've come to believe that XP is not a silver bullet but is a solid step forward for a very specific kind of software development and not at all great for engineering that occurs outside the context of business or vertical product development. XP and other customer-centric, lightweight methodologies are a leap forward for (a) biz-dev, (b) work for hire, or (c) small to medium IS programming where large-scale reuse or where "programming for the future" are not high priorities. However, I don't see any evidence that it works well for commercial software development or other forms of development where innovation is as important as meeting potential customer requirements. This include research projects with unclear goals or ProductLineArchitectures where reuse is a high priority -- especially when unknown future products need to be integrated from preexisting CoreAssets. Actually, I think XP could severely hurt these types of projects.
One of us probably me does not understand Xp. I come from a research Environment where often our first and only user story for the first month was, it dont work, or we have all this data that we dont understand but think it must be useful. Open ended to the point of being ludicrous. At the time I had never heard of Xp, but when I did I noticed several friends and several if only I had done more of that. In a ProductLineArchitectures I would expect that refactoring and lots of unit tests would be a god send for extracting and generalising useful objects safely out of a project and into a common library. Worked for me. In the ProductLineArchitectures clearly this development is for two clients, the reuse library, and the product. One of them pays for the user story or they share it.
I know it gets flaky around the edges trying to tie every development and feature to a user story in these environments. I find I need to invent to predefined universal user stories. I want the next project cheaper than this one (reuse). I want to be able to change my mind about the features in this one cheaply. This second story justifies putting in some real framework here and there instead of the simplest thing that can do the current (this weeks) feature set.
I think it is usually a mistake to evaluate XP against general computer science qualities. XP excels at business development, projects that are applications, where the customer is well defined and his/her requirements well known. Why must XP be good at everything? These kinds of projects are very different from R&D where innovation is a key deliverable of the project. In fact, innovation and anticipatory work could actually hurt an XP project and vice versa.
We need to remember that application development does not make up the entirety of ComputerScience! When programmers say ComputerScience programs suck, what they really mean is that they suck for those engineers who do business development. This is one of my big problems with much of the Wiki material about ExtremeProgramming -- an assumption that all engineering would benefit from an XP approach. If someone mentions a project or environment that is not appropriate for XP we either hear (a) from those who say this is a flaw of XP or (b) from those who say this is a flaw in the approach taken by the project. How about just saying this is not an appropriate environment for XP? I don't think I've ever heard that said.
Can you imagine AlanKay showing up in an XP shop as an unknown programmer and pleading to "Play it grand..." or that the "best way to predict the future is to invent it"? I don't think this would go over in an XP shop. But does that mean AlanKay was wrong? Can't it simply mean that XP is appropriate for a different kind of development? What if he showed up and said "A successful technology creates problems that only it can solve"? Would you pelt him with DTSTTCPW or YAGNI? Do we tell him he is wrong? There is a certain kind of thinking for commercial software that is not appropriate for bizdev or vertical solutions (and vice versa). Something I'd like to see on Wiki (or on an XP site) is a suitability to task for XP ...what projects could be hurt by an XP approach and which could be helped? After all, we don't use the ObserverPattern to solve every design problem under the sun, do we?
Summarizing some of the comments below...
Here are some conditions under which "pure XP" might not be the most optimal methodology:
(...realizing that XP development is already designed to adjust practices to situations it encounters.)
(If you're not going to use XP to address these issues, then what are you going to do? Just giving in to CowboyCoding is not much of a plan: What's your non-XP approach that would solve a problem that XP can't handle?)
Any non-XP approach is a viable option. I have a book before me chock full of methodologies, technologies and tools that have been successful at some point in the history of software development. The question is not whether XP can handle the same set of problems (although a breif glance at methodologies that attack certain problems [e.g. concurrency] explicitly lead me to believe this could be a valid question). The question is rather; For a given problem which would be best? Our chosen non-XP approach or XP.
To say that XP should be used just because it can handle a given problem is wrong. This assumes that XP supersedes and makes redundant all other techniques. And arguing for the use of XP without making comparisons seems to me rather like pitching David against Goliath when Goliath is on his hols. David, in short, has a free hand.
Robert, any thoughts on what sort of practices you would add (or remove) to move outside of the business (or small team) context? -- ErikMeade
Well, I think that doing the right thing instead of the simplest thing might be more important. I also think, anticipatory design wouldn't always be as bad a thing for a product as it is for an application. After all, with a product, you want users to find new and creative uses you hadn't (completely) planned. Also, the UserStory thing changes a little, but I'm not exactly sure how. You want to be careful because while Marketing may be your direct customer, the user-base (potential and existing) are your ultimate customers. -- RobertDiFalco
I ask myself this question every so often, and it always seems like the wrong one. It feels too broad. When is testing a bad choice? When is working in pairs a bad choice? When is refactoring a bad choice?
I don't think I'd ever look at a situation and say, "Well, I guess we'd better not use XP here." It might be true - in fact, it might be true most of the time - but it's not a useful way of thinking. I certainly might say, "Well, I guess we'd better do some more up-front design here."
-- AdamSpitz
But Adam, you are talking about some of the BestPractices that ExtremeProgramming uses. When we say XP, we are talking about a complete set of these used in a highly disciplined manner. You can do PairProgramming and testing and refactoring and still not be doing XP. -- RobertDiFalco
Right. That's why I don't like thinking in terms of whether XP is a bad choice or not. It's not a useful distinction. It doesn't help me decide which practices I should use.
How many people do you suppose have heard someone say, "XP isn't suitable for very large teams," and then neglected to look deeply enough into XP to learn that they might still want to be doing UnitTests and PairProgramming?
(I don't know the answer. Maybe it's a small number. I'd prefer that it be zero.)
I'd rather have a discussion about each of the individual practices - when it might not be appropriate, when it might not be possible, when it might not be enough - and learn how to tailor the process to my own situation.
-- AdamSpitz
The software industry is full of those discussions. But what's the point? As you said, it would make the question too general -- i.e. code should always be unit tested. What is unique about XP is the way those best practices are collected and used. These pages attempt to scope XP as a whole rather than its various practices taken one by one in isolation from one another.
Fair enough. Just remember not to throw the baby out with the bathwater. -- AS
I also have a question, what development houses not currently doing Xp are likely prepared to jump in boots and all and do Xp as a whole. Are these pages just for the fully converted? Are requests to have a discussion here with Xp experts denied, do people who just want to try a bit of Xp encouraged to go elsewhere and talk without you. If so I think I just spotted the next dinosaur methodology being born.
It was stated above that (...realizing that XP development is already designed to adjust practices to situations it encounters.) but now with anonymous and presumably authoritative statement about the software industry and about what these pages are about we are back in all or none territory. My head is starting to spin. You cant have it both ways, either you are a dogmatic autocratic all or none religion or your are prepared to discuss things including scope.
Also without clear migration strategies on how to get from where I am at one new step at a time to Full Xp and without clear suggestions about the order and the payoff for each step taken, who is expected to make the journey? If we do not get the guidance here who leads the way? Too late, I see my own road Bye.......
There is guidance. Look around here. Have a look at ExtremeProgrammingApplied or ExtremeProgrammingInstalled.
I think it would be more helpful if people suggested alternatives to XP and where they would be superior. To just say XP won't work provides little guidance as to what else to try.
I can't imagine designing a (useful) sort algorithm using TDD. Nor many other algorithms. Will unit tests prove our encryption is good or our system is secure? Can unit tests show we meet Real Time constraints, avoid Race Conditions or Dead Locks? NickKeighley
EditText of this page
(last edited April 29, 2014)
or FindPage with title or text search