If Xp Isnt Working Youre Not Doing Xp
If Xp Isnt Working Youre Not Doing XpA caricature of a frequent response to challenges to ExtremeProgramming. See PixieDust.
[See IsXpUnitTestingBest for some questions about the XP definition of UnitTesting, for instance.]
Frequently, someone will volunteer his experiences with ExtremeProgramming, and conclude that it (or some part of it) doesn't work.
Since many of the XP practices depend on other XP practices, it's legitimate to ask: "Were you doing all of XP when you had this experience of failure?"
Some readers mistake this response for the (unfair) response: "If XP isn't working, you're not doing XP." This clearly has problems, since it excludes any possible evidence against XP (the DogmaticFallacy).
So when you see an exchange like this, try to carefully figure out what's being said, and respond appropriately.
-- GeorgePaci
It's difficult to see how the question "Were you doing all of XP when you had this experience of failure?" is a more legitimate response. It seems like WeaselWords actually, to raise the idea by implication that the failure would not have happened if the person was doing all of XP. It is also raises the presumptive association that the person was NOT doing all of XP, or the question would not need to be asked.
In fact I was just reading something in ProgrammersStone apropos this, in the example of auditors (in an ISO9001 environment) going around looking for problems, and assuming when problems are found it is the individual's error in following the process that caused the failure, but the presumptive condition is that the process itself is flawless.
In reversing the assumptions one comes up with a curiously dismissive result: The person experienced failure. The person was doing all of XP. Many XP practices depend on other XP practices. The failure in one area, by virtue of those very dependencies, is a failure of all of XP. Ergo, to save XP, it must be asserted that if XP isn't working, you're not doing XP.
Please note - either extreme is flawed to the point of being downright silly. I would like very much to discuss XP without the requirement that there is either "only doing all of XP succeeds" or "XP fails as a whole"
-- StevenNewton
I'm one of the people who asks "were you doing x" when you thought you were doing XP and had trouble. Here's a real example.
I visited an XP team who were writing lots of tests, and doing refactoring, trying to keep their design simple. There was just one little problem area: they weren't getting stories from their customer (though they were getting requests), they didn't have a release plan, and they didn't know their velocity.
Now I think there is big potential trouble here. The reason is what I call the Circle of Life (see my chapter of the same name), where the customer defines what has value, the team estimates the cost, the customer chooses value based on cost, and the team does it. In shorter terms: these guys aren't focused as much as I'd like on keeping the customer satisfied.
If they were to get in trouble, would it be a problem with XP, or with the execution, or something altogether? I think it would be unfair to blame XP, and at least a possibility that the execution was the problem.
When any project goes off the rails, the best way to learn is to do a retrospective inquiry into what happened. If the team was following a defined process, part of that inquiry should - I think - find out how well they followed it. Whether they followed the process perfectly or not, there's information to be had there.
Every process can be improved, and every team's execution of their process can be improved. When things go wrong, I'd like to know why. And I'd like for the process to take the heat for its flaws, and the execution to take the heat where that's appropriate.
Am I off base with this thinking? -- RonJeffries
No seems spot on to me, but problems arise. To fair and balanced we must then also ask every person every time they claim, 'Xp worked for me', did you do All of Xp all of the time for all of the project. If this is not true then it is not fair to complement Xp for all of the result. Perhaps this project was saved from failure by the deviations. See paper tiger alert below for an example of how absurd this seems.
Not only that but to be impartial we must also ask what else did you do that is neither required nor prohibited by Xp. For example on another page Kent has said anecdotally that when 'he' did refactoring the result was code that was 'radically decoupled'. Is this an attribute of Kent or the process. I know where I would place my bet if I was asked to decided is it easier to 'use the process and get coupled code', or to 'use any process at all and get Kent to write coupled code'. (I dare him to deny it :) If it an attribute of the Xp process that I have read about that code winds up radically decoupled then I am not sure how it happens.
It has always concerned me that a combination (perhaps an over-zealous one) of YAGNI and the simplest thing that could possibly work would wind up in code that was hopelessly coupled, because after all you are not going to need the flexibility provided by decoupled code (literally YAGNI). The SimplestThingThatCouldPossiblyWork and satisfy the current set of user stories is always coupled code. If however the primary user story, which most users don't even know they have (so we have to write it) is, "We (the users) are going to radically change our minds, add new features, redefine old ones and then delete them." Then suddenly radically decoupled code is an 'you are going to need it' (YAGNI!). When I build I project I measure my safety (lack of design smell) by the number of decisions I have not made yet, and the number of very YAGNI what ifs that still have obvious easy answers.
Code for me smells for pretty much exactly one reason. I try to change it and find it difficult. It is usually hard because of decoupled effects in the code and thus there are mysterious and non-local effects. Change here break there. Arrg. To produce decoupled code, my story (not the users), I need to make encapsulated objects that each fulfil all of a responsibility. The 'all' is important, When its easy I sometimes add stuff I don't need yet because clearly it belongs there. (Eg an unused accessor, All of the C++ abstraction to make this smart pointer behave like a real pointer, All of the std stl accessors to this hash table, just like other standard containers) Why? PrincipleOfLeastSurprise and it's easy. I now can write in 25 words or less. 'hashTable works a lot like std::Map but accesses data in constant instead of log time. Beware the iterators are a bit different.'
If it is harder, I may add a commented out function prototype. If its non obvious and harder I will also write a comment saying how to do it. Do these violate YAGNI or not? so far I can't tell, do I do Xp will I ever do Xp, am I good husband? I suppose the answers depend on whether the project succeeds and whether or not my wife leaves me!
To wait for this however is too late as the inability to change code indicates that it smelt last time you wrote it. To tell if the code I have just written smells I apply the same test but as a thought experiment. What if those YAGNI features become critical must haves? Can I still do them easily and with contained changes. If not the code probably smells enough to fix it now. Have I violated YAGNI or fixed smelly (not radically decoupled) code? Are the undoubtedly clever and talented proponents of Xp who describe it successes actually describing the properties of Xp or the properties of Xp plus their own expertise, or perhaps even the properties of their own expertise despite Xp.
Open Question: Are there ANY CodeSmells that do not break tests and do not make code hard to change, that are worth fixing. If so where is the payoff to the customer?
The problem also is that if we only evaluate the cases where all of Xp has been done and compare it with the cases where none or not all of Xp has been done then the quality of the staff involved is likely to differ markedly (IMO).
It is however also true that detractors (Anti Zealots) will turn up from time to time with paper tigers and say 'We tried pair programming and it failed miserably'. A suitable response that avoids the classic 'but did you do all of Xp' is the more open question that simply asks them 'to describe all of the process they used, and in what way it failed'. If the answer is that 'I and George wrote this really nifty task scheduler and a couple of newbies on the team changed it and broke it irreversibly.' Then several obvious questions about unit tests and source code control exist. The best way in my experience to deal with most zealots of all flavours is to let out enough of the right kind of rope and have them shoot themselves foot.
To get real and really evaluate Xp is not going to happen. To do that we would need real experimental settings, real projects, real users, real development teams all times N so that we would get statistically significant results that control for the effects of 1 really good coach. 1 Type of real world problem, especially suited(or not) to XP, and so on ad infinitum. Experimental psychology and in this case Sociology is really really hard to get right, It is harder than writing bug free code!
On the other hand IMHO:
It is inconceivable, to me, that adding some more UnitTests to most projects would not make things (much) better. No other Xp changes required. Turning just that knob up from 1 to 2 should make things better. If it does not it would take serious explaining why it only works when you get to Xp's 11 and then it only works if you also do everything else.
There are other rules such as:
Example of 12+ on PairProgramming. Team of 6 programmers, one is sick today. Draw straws and send their partner home too. No pair no work.
Example of OnceAndOnlyOnce turned up to 13. My program in C++ has one and only one for loop, one if, one ... How I hear you ask incredulously. I put them in templated functors and reused them :)
Example of OnceAndOnlyOnce turned up to 26+malice. My program also has one variable declaration and an otherwise empty int main(). How I hear you ask very incredulously. I instantiated a rather heavily nested functor template definition OnceAndOnlyOnce! I get cowboy of the week award, (probably the year, but the competition is tough).
Example of YouArentGonnaNeedIt turned up to 26+malice. My UserStory and hence the UnitTests indicate that the program should 'be able to add up numbers'. My program can 'add up numbers'. It can add 6 to 4 and get 10. Not only that but I added validation that confirm that the user entered legal values and that they are 6 and 4, respectively. My program can 'add up numbers'. I have however heard that the user wishes to change this stories wording a tad. What I shame I didn't have that specification locked down in legalese, I could have made a fortune enhancing it to 'add any two 6 digit integer numbers'.
-- Mr Grey
PS. You may wonder which side I am on. Sorry I checked my side arm at the door but I am not so sure that everyone else did.
"Not working" seems rather vague. Anyone critiquing a software process (but to be fair, its outcomes really) ought to be able to say something more specific than "it's not working". Is the functionality poor? Is the code hard to maintain? Are schedules being missed? Is management unhappy? What?
Asking 'were you doing x?' is subtly but importantly different from 'were you doing all of XP?', in that it doesn't insinuate that the failure is tied to XP being all-or-nothing.
But you see, "were you doing all of XP" if taken as a question, which it is, a quick answer: "Well, we weren't doing x or y, but otherwise ..."
[This discussion comes from a statement on another page... "Once again we see the fallback: if XP isn't working for you, you're not doing XP [right]."] [...] where a debate focusing on whether or not the failure was because the execution of XP-style UnitTests was flawed threatens to obscure the necessary and useful examination of whether or not XP-style UnitTests are as effective as some other kind of unit testing, or some other (non-XP) practice entirely, say code reviews. -- StevenNewton
When someone has problems with XP (or any other methodology), the question "were you doing 'X'," where 'X' is part of the methodology, and 'X' might have reduced or eliminated the problem, seems like a reasonable questioning. -- JeffGrigg
From StevenNewton, above: It's difficult to see how the question "Were you doing all of XP when you had this experience of failure?" is a more legitimate response. It seems like WeaselWords actually, to raise the idea by implication that the failure would not have happened if the person was doing all of XP. It is also raises the presumptive association that the person was NOT doing all of XP, or the question would not need to be asked.
Throw in a Klieg light, a riding crop, and a cheesy German accent, and I'd agree with you. You can ask just about any question rhetorically, to score debating points.
But on Wiki, it's not asked rhetorically, and the questioners listen to the answers. They're interested in finding any problems with XP and fixing them. It's not a debate; it's a tech-support call.
As for implications and presumptions: well, the person asked gets to respond, which then trumps any implications or presumptions with their actual experience. For example, "Yes, I was doing all of XP." So now the XP proponents have a useful case where XP didn't work, and can bang on XP until either it will work in that case, or it's flagged as not working in that area.
How would you suggest an XP proponent who's genuinely not sure if someone is doing all of XP find out? -- GeorgePaci
Has anyone who has stated "XP didn't work for us" actually been able to claim they've been following the principles and practices?
For my reading of the XP mailing list and newsgroup, the most vehement claims of "XP didn't work" described situations where XP was clearly not being used. In particular, it appears that testing, iterative development, refactoring, on-site customer, and the Planning Game were all neglected.
The question "Did you follow all of the XP practices?" is quite a natural one to ask when the vast majority of claims that XP didn't work seem to have come from environments where the XP practices were _not_ followed. -- RobertWatkins
A related question is whether or not XP is falsifiable (in the sense that one can construct an experiment which, upon giving a certain result, would show that XP-as-stated is false). In general, people seem to want to justify or refute methodologies by anecdote, which leads to semi-absurd debates like those discussed above. However, before you can really get into the issue you need a formal statement of XP's claims which is falsifiable.
Some examples of non-falsifiable doctrines include most if not all religions, Marxism (Leninism, Stalinism...), and psychotherapy as outlined by Freud. They have the peculiar characteristic that their adherents can never be proven wrong; I have met Leninists who insist that "true" Leninism has never really been tried, and that the failure of Leninism in any given country is proof that they were not practicing true Leninism. ;)
-- JamesWilson
Here's a hypothetical experiment to test XP versus some other methodology. (It would cost a tonne of money to do, but it is theoretically possible to verify the validity of any methodology this way.)
Prerequisites: Clearly define the two methodologies in terms of practices and measure the degree to which those practices are followed. Clearly define the meaning of 'project success'.
Start N projects with XP and another N projects with some other baseline methodology. The greater the N, the greater the accuracy of the experiment. The more closely related the projects are, the greater the confidence in the results. Ideally, each of the N projects done by XP would be the same as one of the N projects of the other methodology (i.e. the same project would be cloned and tried with each methodology). Complete all of the projects and compare the results. Measure such things as cost, number of features, customer satisfaction, developer satisfaction, the project's success in the market, amount of reuse, etc. I'm not actually an expert in this field, so I'm just making up measurements as I think of them. If XP succeeds more than the other methodology, based on the prerequisite definitions, then XP has been validated. If it succeeds less often, then it has been 'falsified'. -- RobHarwood
From the /. discussion of a review of XP Installed:
"If a methodology is so fragile that the tiniest deviation leads to failure then that methodology is worthless in the real world" [http://slashdot.org/comments.pl?sid=10258&cid=470691]
And since XP is being used in the real world and clearly isn't worthless, we conclude...
...That at least /. keeps most of the idiots off the Wiki? O:-) [So, it can't be worthless, either....]
The StrawMan embodied in the page title reminds me of the classic counter-argument to Darwin's theory of natural selection; it goes something like, Darwin's is a theory of the survival of the fittest, wherein 'the fittest' are defined as those who survive, and thus the triumphant QED that the theory is based on circular reasoning.
As seen in some forums, and most recently on Slash, the XP version goes, we tried XP and it failed; if you ask whether what we tried was indeed XP and not a different set of practices arbitrarily termed "XP" by whoever was responsible for imposing them, then you must be guilty of unfalsifiability.
To counter the argument, it should be sufficient to point out that there is a difference between saying "we tried XP and it failed" and saying "our coding pairs tried having complete UT and AT coverage of a collectively maintained system described by a simple metaphor and constantly refactored to its simplest expression, frequently integrated and released to a maximally available customer, all the while having fun and not doing much overtime, and it failed". -- LaurentBossavit
First off, I'm not a member of the anti-XP brigade - I am actually using XP (or so I think!) in my current project and am happy so far. But no, it's not sufficient to restate things like that, because the more specific criteria are all still open to subjective judgement and are not precisely enough stated to make XP falsifiable (one could plausibly doubt whether or not a team's metaphor was simple enough, its refactoring constant enough, etc., since these aren't really precisely quantified).
Large-scale studies as suggested above would have the same problem of imprecise definitions. For what it's worth, I suspect that most if not all methodologies are not falsifiable either and so should be considered on par with religions. ;)
-- JamesWilson
Paper tiger Alert. beep beep beep. (no offence intended James)
Great James you are just what I need. Are 'you' doing all of Xp? To speed the conversation up, I will ask a directed question to which I can guess the answer, do you have a full time on site customer and did they write (not agree to) the AcceptanceTests?
If not then I have an explanation of why your positive experience with Xp is a mere artefact of you not doing all of Xp. If you had insisted on doing 'All of Xp' then your project like many others would almost certainly fail!!!
Why? Because with the current level of knowledge about Xp in the user community most attempts to use all of Xp will either fail to use all of Xp or fail to get off the starting blocks when the programming team insists the customer play all of their role. -- Mr Grey
Who said anything about imprecise definitions? Pragmatism is where it's at. Come up with a definition based on observable practices and there ya go. No muss no fuss. Research like this does take place (though probably not to the scale listed above), so don't discount it too quickly.
I believe the comment about imprecise definitions is an extremely valid one and should not be so lightly dismissed. On one hand we are told it is required to do all practices, but when someone asks how to do the practices, the answer is go figure it out yourself. Most of the practices of XP are described in a highly subjective manner hiding the intentions. This level of imprecision leads many to conclude that XP is just glorified hacking, and frustrates those of us who are trying to gain an understanding. -- WayneMack
Wayne, what I mean to say is that when one is doing a study, one must precisely define your terms. When we're talking about it on Wiki, it's not so important. For example, see the PairProgrammingResearch done by LaurieWilliams. In it, she defines, within the context of the research, what she means by the term 'PairProgramming'. If someone were to do a paper trying to falsify XP, they would have to define clearly what they mean when they say 'XP'. (Ideally, the person to do the first definition would be someone like KentBeck, but that's another story.) If someone disagrees with the definition, they can always do their own study and define XP the way they want. It's not perfect, but that's how it works. Eventually, the definitions average out to be more or less what XP is. I'm not dismissing the definition problem, I'm describing how to overcome it. -- RobHarwood
Shouldn't the inability to use all of XP be considered a problem (if not a failure)? Requiring 100% adherence to all of the imprecisely defined practices seems to limit XP to a very small possible problem set. If XP is going to be a true software development methodology, it needs to become more flexible and open to partial use of its practices. -- WayneMack
Our team had trouble using all of XP. We learned things from XP anyway, implemented UnitTests, PairProgramming, and OnsiteCustomer, never managed to get any of the other practices going, and did quite well.
Perhaps this is a failure of XP. I don't know.
-- AdamSpitz
A three-legged stool can stand. Remove one leg and it cannot.
The idea that IfXpIsntWorkingYoureNotDoingXp sounds to me just like the circular argument for deregulation given by FreeMarketeers around the world. It goes something like, "If you're having problems in your deregulated market, then you clearly haven't deregulated enough. Sprinkle on some more market and everything will be fine." California's energy problems are a good example.
What you may be missing is that no one in XP believes that IfXpIsntWorkingYoureNotDoingXp. When people say "we tried XP and it didn't work", we do explore whether they were in fact doing XP - but the definition of doing Level 0 XP is quite unambiguous and clear: the 12 practices, all the time. If someone were doing all 12 and "it didn't work", we'd want to figure out what was going on. If they're doing everything XP except they don't have any UnitTests ... well, I wouldn't call that XP whether it worked or not. -- RonJeffries
The funny thing is, the same thing can be said about regulations themselves. A law is passed, something horribly wrong happens, and legislators yell "We didn't regulate enough!" and add on even more regulations...which cause even more problems. Trying to unravel the mess is difficult, too. I cannot remember the details, but I remember someone making the case that California's deregulation only removed rules from one side of the equation (and for the life of me, I don't remember the "sides" involved), which created a certain imbalance, which in turn caused California's energy problems. Rules are funny things--unless you know what you're doing, messing with them (whether it be adding to, taking from, or even just leaving them alone) can wreak all sorts of havok--and it's especially unfortunate that none of us know what we are doing!
And so it is with methodologies. We attempt to adopt what seems to make sense, and hope for the best. Sometimes it works out, sometimes it doesn't...and sometimes it's a complete unmitigated disaster. --Alpheus
Yes, it is clear that UnitTests are a serious enabler for the rest. What about if, the on site user "does not actually write the AcceptanceTest". I will tell you now. If this is a 'take it' or 'leave it and your on your own requirement' then I know of no conditions under which I could recommend Xp to any company.
Apologies in advance but I am getting tired of waiting for Xp to get over it.... The trouble with Xp enthusiasts and I am going to be perfectly rude and blunt is that you seem to lack all subtlety. There is unambiguous White, all '12 practices all of the time' at 11 or Black 'don't have any unit tests'. (How about some grey or better yet green) Sheesh Ron how about describing what if some event between 1 and infinity occurs. Do your UnitTests on your code cover the possible scenarios this badly?
Of course it won't work if you don't have unit tests. Does any serious methodology not have tests?? In Xp if you don't have tests, you can't have refactoring safely, you can't have collective ownership without serious risks, you will miss your regular release dates when HeisenBugs blow you out of the water for a month. Yada Yada Yada.
I might however then recommend nXp which is a remarkably similar excepts that it's proponent (singular) suggests that adoption of nXp is done by turn up the appropriate (self evident) knobs and seeing if it works better. Its proponent is prepared to bet his pay check double or nothing that it will.
-- Mr Grey
PS. It may be hard to tell, but I am in fact closer to being on your side than any other side, I just want little grey in the discussion.
Will Xp work all of the time? Nope, give me a silly enough client and a big enough bunch of drongo programmers and I can make any methodology fail. Will Xp work if you do some sensible subset of the practices most of the time. Bet my paycheck on it.
Do the Xp promoters go that far? Nope they hide behind 'but the definition of doing Level 0 XP is quite unambiguous and clear: the 12 practices, all the time'. Seriously Ron, I have seen used car salesmen and real estate agents run for cover less quickly.
'Bet my paycheck on it' Example thought experiment
For example do BigDesignUpFront, do lots of UserStudies? and modelling up front, plan on there being no users within in cooee during development. Give me an Xp team to try and implement the architects design and unless the architect is really really good or the problem so well known and simple that I don't know why you didn't buy the answer off the shelf. I bet we find issues the architect did not think about. I bet we find user questions he does not have documented answers to and thus has to guess. When he does not have big upfront documented answers, I want access to a real user. I want to show them the current iteration and I will bet my pay check they have changed their mind about their documented requirements. I will then bet my doubled pay check that we can cheaply, because of the unit tests that we added cheaply a make the user happier and thus a return customer.
Note this is not fair bet. It is rigged. I am not JustaProgrammer.
Does Xp work. Absodamnlutely it will even work if the right (not the wrong) half of Xp is broken. (Do NOT leave out UnitTests.) Can Xp fail, Absodamnlutely, the skill of the people in the team is also critical. Xp needs at least a 13th practice, do not hire too many drongos. (oz slang) How dangerous (what's the risk) are drongos to Xp? A lot less than any process without PairProgramming and UnitTests. When will BigDesignUpFront work? Every time you reinvent the wheel. Will Xp fail on any project? Not if you hire the right team. Will Xp excel on any kind of project? Evertime you want to get outside the box and go to new places.
This, above is real advocacy, I am tired of smoke and mirrors from Xpers, 'Put up or Shutup' (more oz slang) and get out of the way.
-- Mr Grey
Ever since the conception of XP, I've disagreed with the fact that you need to do all 12 for it to be XP. And I disagree that attempting to apply all 12 practices and failing (whether your project succeeds or not) means it isn't XP. I respect that you guys have such strong conviction about this, but I think it will hinder XP's ability to be successfully adopted, especially by your standards.
If XP was positioned more as a reference model for an adaptable pool of interacting practices, then I think it would become more ubiquitous in the software development community. By your standards, I've never done XP in the twelve years I've been in the business. By my standards, I've done it in many of my engagements. (By done, I mean that I've used a subset of XP's practices.)
In closing, what do you think I should do now? Should I stop telling people I do XP, since I'll never be legit in your book? If I succeed by using a subset of the practices, what value is there in disqualifying me from the official XP seal of approval? Gee, I feel like the duck in those AFLAC commercials ;-)
-- Mr Grey seconds your positions but got tired of being nice about it and asked them to get out of the way. If as they claim Xp only works, or they only want to talk about it, if the world is perfect, Dilbert is fiction and not reference guide, etc etc etc. Then the next time I note than no-one reads Dilbert or finds it funny anymore, I will look them up. Meantime I need a process that I can sell that, can be adopted gradually piecemeal, will demonstrate incremental improvement, I have way too few change dollars to make the whole Xp shebang fly anywhere anytime soon. If any potentially methodology fails to meet any one of these criteria, then it not an adoptable methodology and there is no point in waffling on about a dead rat.
Seeing as Ron has ruled out adopting Xp slowly (It is 12 practices or you're not Xp and thus the Xp world disavows any knowledge or advice except do it all) does anyone else have a suggestion where I should go to find an alternative that is adoptable by being adaptable?
Advice to Xp advocates. Just because people throw rocks does not mean that you should dodge. Perhaps it would be better to stand still and shine a strong light on the criticisms. If people in fact claim they did Xp and it did not work but they admit they did no UnitTests, just let them shoot themselves in the foot. If they didn't do that stop saying -- Mr Grey
In a world with RUP, I appreciate there being a stake in the ground. Give a manager a single optional practice and she will screw up the whole smash.
XP is being born into a rough neighborhood, so it needs its hard shell for the moment. Adults who know that rules can be broken may, of course, break them. Just don't be a baby and blame XP if things go sour. It could be that you chose to break the wrong rule. It could be that there were constraints outside your process that were going to keep any methodology from succeeding. -- WayneConrad
I feel like you are describing a context that is rife with people who haven't built software before, or is controlled by managers who haven't the slightest clue on how to lead projects. For me, it's not about breaking rules, or choosing the least common denominator because of a constrained development environment. E.g., not following the FortyHourWeek practice essentially disqualifies all investment banks and all start-up companies or any environment where people like to work in a fast-moving, intense, challenging environment. And it totally disqualifies me: I might work 100 hours then 45 then 60 then 55 then spend a weekend in the Keys scuba diving, and come out totally centered. -- PhilipEskelin
The rule should be called SustainablePace, not FortyHourWeek. The notion is that productivity does not increase with hours worked. Tired programmers are less productive than well-rested ones. Teams in investment banks, start-ups, and "fast-moving" environments ought to know for sure whether working 100 hour weeks is actually more productive than some other number. -- RonJeffries
EGADS Ron further up this very page you said and I quote 'but the definition of doing Level 0 XP is quite unambiguous and clear: the 12 practices, all the time'
Are these unambiguous always to be followed all of the time practices the same ones we saw in AnimalFarm? It is unambiguous that we must do 12 practices yet you now tell us it is sustainable pace, and consider the value 100. Could there likewise be 30 practices we have to unambiguously follow. Perhaps in reality, Xp is a sign post and if you come hither it gets better, and there is not magic 12 or nothing bullet.
-- Mr Grey
The most perfect example comes from GreatFailureOfXp (emphasis his):
Yeah, well... This isn't about Philosophy 101. Or if it is, Quine is who you want rather than Plato. The words quoted above are mine. The distinction above is between "I just don't grok what this XP thing is all about and how we're supposed to use it", versus "We did the whole XP shtick as best we could - 100% XP minus some epsilon - and we still managed to write software that sucked".
There is an intermediate observation, not discussed on GreatFailureOfXp, which is "We did some of what XP recommends, far from 100%, and the project failed".
In the "don't grok XP" and "partially XP" failure cases, there are responses from people who do grok XP which, if you interpret them as if they were responses to "did all of XP" failures, will give the illusion that what is said is "IfXpIsntWorkingYoureNotDoingXp".
I claim, pace Sunir, that in all cases where someone seems to be saying "IfXpIsntWorkingYoureNotDoingXp", it is because of a misinterpretation of this sort, honest or willful. To knock down the claim, it is only necessary to point to an instance of someone saying, "We did all of XP and failed", and someone else responding, "You can't have been doing all of XP". -- LaurentBossavit
I think the response, "IfXpIsntWorkingYoureNotDoingXp," is mostly to people setting up their failed projects as XP strawmen. Thus, they say, "XP failed," when really they weren't doing XP. Of course, this is obnoxious to those who would like to see XP gain more mindshare. So, they naturally cut the person down as a failure himself.
However, I don't think it's the best approach. Since it's essentially cultlike to rally around a methodology - on par with Linux advocacy ;) - the failed individual will look even more unkindly towards XP after such a beating.
I submit, in order to gain more positive mindshare, one take a more socialist tact (based on the NonMethodology?). Instead, constructively engage the individual. Identify the real problems he experienced and work to prepare responses for future projects. Then, instead of spouting the normal XP mantras - which don't work unless a project is already on the road - you can engage troubled projects at the level of helping them out of the ditch.
We could make a derailed XP pattern language. There's already some work on helping with the start-up phase done on AdoptingXp. We can build on this for the remaining aspects of the software development process. -- SunirShah
[From ExtremeProgrammingLimits?] A previous attempt at such a discussion failed by a huge margin. See ExtremeProgrammingBoundaryConditions. Basically the general attitude of XPers is that if XP doesn't work, than either it is not applied properly, or there is a problem somewhere outside XP (like bad/inflexible management, company politics,etc, etc). I thought XPers should be able to do better than that.
I don't think any XP spokesmodel has said the above. It is true, however, that at least the following things can foul up your attempt to use XP. Does it seem otherwise to y'all?
Teams don't get an on-site customer, and/or don't pair and/or don't refactor. They report that "XP" didn't work. Should we look further into the case to see what went wrong with XP? Seems that it would be like looking into the kitchen at McDonalds to see why XP doesn't work: they weren't doing it.
However, if you were confidently serious instead of defensive you would find out if the failure seemed related to the missing pratices. There are not enough cases of we did all of Xp and it worked. Also if Xp advocates can't get their act together and engage the partial adopters in constructive help rather than a not interested, I never expect a dent to be made in the non early adopters market. If you don't have an onsite customer then I expect you to produce the wrong product effectively, or that when feedback did come it required large changes in direction. I don't expect to hear that the tests took forever to write or that refactoring became impossible once the code base became large. If it did then I have cause to start to wonder about the process. -- Mr Grey
I have worked with teams that didn't let the customer make the decisions the customer is supposed to make. I have seen teams where management insisted on telling the programmers what to do. I have seen teams where someone high up decided that the project should be terminated. Should we be looking into these cases to see what went wrong with XP? What might be improvements to XP per se that would help with these problems?
Hey maybe if you have seen all these things then there is nothing except that stuff wrong with the other failing methodologies. Does the company have to be otherwise perfect? Is Xp in your view fault intolerant? If not address why it fails in the presence of any other fault. Or start with which faults it is intolerant of. Personally I seem to believe in it more than you! -- Mr Grey
I have worked with teams where the QA department provided all the testers for the team and they were "busy" writing automation tools. The programmers felt that the testers should write AcceptanceTests, so went ahead without acceptance tests. Should we be looking into these cases to see what went wrong with XP? I think not: I told them: "The team must deliver acceptance tests every iteration. End of story."
Now perhaps this is troubling to some. But so far I've not seen a case where a team said "We're smart people, we followed all the rules for six months, we paid attention and made these modifications based on what happened, and we produced crap software on a completely random schedule".
Personally I have never on team of smart people using any method, that failed in any way that was not externally imposed by outside forces that the method said should not happen. This is at least partly what is wrong with other methodologies. They don't really work in the wild, where things are wooly and change and nasty things happen. Again I ask is Xp in your view fault intolerant. -- Mr Grey
I don't think XP is any kind of silver bullet. I think that to really assess it, you really have to do it, not some other thing. And I think XP is also not bulletproof: a sufficiently violent outside force can kill it.
Yes these statements are clearly true of everything. Which makes them content free. Except perhaps the immovable object is bullet proof and the irresistible force is sufficiently violent. -- Mr Grey
Whenever a project fails, people look for reasons. And the people there generally always know the reasons. I expect that any competent report on XP projects failing will include the answer on what went wrong. I don't know what went wrong, but I don't expect to see "we kept the code too clean" or "we tested too much" or "we worked together too effectively" to be among the leading answers.
Quick count the escape clause in that paragraph.
If Xp principles are motherhood statements like 'keep the code clean' , 'work together effectively' then I am out of here. Fortunately it is not.
When a project fails it fails for reasons, and people know the reasons, and I don't expect to see, we had lots of UnitTests, RadicallyDecoupledCode?, and when we refactored it broke later in strange and mysterious ways and we could not even back out the changes because we could not identify which ones caused the weird behaviour that only showed up in AcceptanceTesting. I also don't expect to see, we got to the end of the project and had no functionality to deliver and no more money, total washout. I also don't expect we had no documentation so we had no idea how the code worked or what the users really wanted so we wound up building what they never wanted in the first place.
I also don't expect to see the client came in half way through and completely changed the spec so we threw out all the code out and started again. -- Mr Grey
But I'm a known fanatic. What are your guesses as to where an XP project can get in trouble, and what are your reasons for suspecting that? -- RonJeffries
You're no fanatic. I am the fanatic. See Bet my Salary above. My problem is you won't stand still. See your sliding on renaming 40 hour week vs the unambiguous statement re all 12 practices all of the time. -- Mr Grey
I won't allow myself to throw (un)educated guesses at a thing I don't grasp. This should be an exercise strictly for the likes of RonJeffries, KentBeck and other XPers, and it normally should benefit the XP itself. But let me quote MichaelJackson:
It's a good rule of thumb that the value of a method is inversely proportional to its generality. A method for solving all problems can give you very little help with any particular problem. But have you ever read a book on a development method that said: 'This method is only good for problems of class X'?
It sure ain't the case of XP. The observations above are only a matter of common sense. So if we take what Michael Jackson said as an working hypothesis, we either have to reconcile some facts, or draw some conclusions. XPers won't admit there's any particular context where XP won't work. Let's consider external politics and "sufficiently violent outside forces" out of scope for this discussion. But there's nothing in XP that says is good for a particular class of problems, or it's not a good for another class.
It can be one of these cases:
Sorry. We can't explain it any better than we have. You do have to try it to assess it. Besides, only you know your environment. -- rj
Firstly Ron you say we, as if you speak for group. I thus feel less bad about referring to that group elsewhere on this page as 'they'. I was concerned that I had been inventing faction out of thin air when it was in reality a group of people who only shared opinions and I was categorizing them for the purpose of tarring them with one brush. I don't quite know who your 'we' or my 'they' are, but to everyone else feel free to include or exclude yourself from my 'they' remarks as you see fit.
You Said 'but the definition of doing Level 0 XP is quite unambiguous and clear: the 12 practices, all the time' So it seems it is unambiguous. You also said we should change the name of the practice 40HourWeek. So it is unambiguous that we must do all 12 all of the time but it is less clear what the 12 are. I would like to try it and assess Xp. This offer of yours however seems a little unfair and high priced(I do not have the change dollars). You have stated if I try Xp but do 'No UnitTests' you will disown it as Xp even if I succeed. (But presumably When I say "I did Xp and It worked" someone would have to ask but did you do all of Xp and then if and only if some asks that question then you will disown it as Xp. Also it is unclear that if I succeed but do some unit tests will I be disowned. I thought some of the practices were pretty crunchy in that it was easy to definitively decide yes or no. Eg 40 Hour week. We could thus do experiments at say 40 and 60 hour weeks and compare results. You comments higher up this page however no longer rule out 100 hour weeks. I really am beginning to suspect that one size fits all that we Xpers want it to.
Elsewhere on the page you suggest you are an advocate of Xp.
Perhaps you are, I however am an advocate of Xp practices. I claim that Fred, a prospective Xp user, should try adding some UnitTests. I suggest Fred try picking some good, important targets and add some unit tests. I claim that this alone will make Fred's project better and Fred will notice. Being in front already, there is no more risk just reinvestment of previous gains in more. I then further suggest that Fred not be stupid and that if some tests made it good more might make it better. I further suggest, that it is possible to write too many and that Fred should keep adding more until the cost/benefit fades out to near 1. I then suggest that with Freds tests in place, Fred might find that some of Freds tested code is cumbersome hard to use and change. Try fixing it, really fixing it. Being a hard task try using two heads and brainstorming some ideas. See if the tests Fred put in earlier save Fred from danger and produce success. I then suggest Fred think about changing but do not attempt, changing some untested code. Is Fred scared? In that case I think I found a reason for Fred to go back and write more tests. Whats more I don't think Fred has to try it, just think about what is said above a decide if that is a low risk plan with potentially significant benefits. Should Fred try the plan? Does Fred think the plan will work even before he tries it. I think the answers to these questions are clear. -- Mr Grey
Above someone writes "XPers won't admit there's any particular context where XP won't work." Is that really true? It seems to me that many of XP practices contain pretty clear limits. For example, an on-site customer is a requirement. So is the ability to do automated testing. And having all your developers in one place is a third. These rule out a lot of contexts for by-the-book XP. Many people are trying to push these limits in various ways, but the XP heavyweights I've talked to have been very frank about how much water is uncharted.
Or is that poster looking for something different, a more firm statement that XP is guaranteed not to work under conditions X, Y, and Z? It seems like XP is too young for such firm statements; right now the best one could say is that "I tried XP under condition X experienced problem A." In a decade we'll hopefully have enough data to make firm statements about where XP works and doesn't; until then I'd be disinclined to trust any black-and-white generalizations about its appropriate use. -- WilliamPietri
I think the question "Are you doing ExtremeProgramming? Are you not doing ExtremeProgramming?" is fairly irrelevant, and moves the discussion into semantics and methodology religion fairly quickly. I prefer a pragmatic approach: "What are you doing? Is it working or not? Why?"
ExtremeProgramming is useful as a conceptual grouping - a set of practices and values that exemplify a specific approach to software development - but less useful as a litmus test. In fact, most good ideas are fairly worthless as a litmus test. The quickest way to get me to leave the room is to start quibbling about the definition of "sex", "art", or "God", though I think sex, art, and God are fairly important anyway.
What I find most compelling about ExtremeProgramming is not its practices, but its values. The practices are just manifestations or iterations of the values, and they may be adapted or discarded as people fine-tune them. If you're looking for ExtremeProgramming because you want to follow a recipe book to SoftwareSuccess, you run a high risk of failing no matter what you do. IfYouMeetTheBuddhaOnTheRoadKillHim?. The values are vaguer, harder to define, fairly impossible to quantify. But these amorphous things are always the things that stand the test of time. (see also ExtremePracticesVsExtremeValues)
IfYouNameItTheyWillBlameIt. We have already seen this happening with claims of "WeTriedXpAndItFailed". That's why "Are you doing ExtremeProgramming? Are you not doing ExtremeProgramming?" are relevant questions. If you already buy into XP, they're not relevant, but if you're critiquing XP, they are.
Thoughts about ExtremeProgrammingInEnemyTerritory? ExtremeProgrammingForOne?
Spleen vented. Feel free to refactor me. -- Mr Grey Mr Grey, you have yourself a huge fan.
Moved from XpVsStandardDefinitionOfUnitTest
<from CthreeProjectTerminated>One of the problems I suspect with C3's aftermath (at least as told here) is the marketing of XP, OO, etc. as the One True Solution. This is fundamentally why "all methodology is crap," I think. When you push a particular package as The Way, you are going to fall on your face because it just isn't The Way. (This is sometimes just deserts to those who make money from methodology as fear-mongering.) So then people are just going to brush aside the whole package instead of taking what's useful. For instance, I liked the discussion of XP on Wiki because it taught me how solve problems in new ways and why those heuristics worked. I don't write UnitTests, but I do refactor even more mercilessly than before. -- SunirShah
Refactoring is changing the implementation of a feature without changing its functionality. Without tests, how do you know you are refactoring?
Well, I know WhatIsRefactoring. Refactoring is not as valuable as reworking (WhatIsReworking). See UnitTestsReconsidered for why I don't UnitTest. However, after much discussion (as on this page), I don't think XP UnitTests either, strictly speaking. -- SunirShah
I refactor without AutomatedRegressionTests, but I know that the practice is dangerous, so I'm very careful. (I'd rather have UnitTests, but you can't always get what you want when ExtremeProgrammingInEnemyTerritory.)
Refactoring Notes: I went through Mr Grey's (now two-month-old) comments and cleared up the attributions. Spacing, rules, and signatures were added; nothing was removed or changed. Maybe now I can follow the argument... -- GeorgePaci 16-Apr-2002
Grammar was improved in a number of places, including Mr Grey's comments. -- a WikiGnome, 2003-02-27
See IfFrameworksArentWorkingYoureNotDoingFrameworks, WhenIsXpNotAppropriate
EditText of this page
(last edited February 24, 2012)
or FindPage with title or text search