Xp Challenge Ten Years Later
Xp Challenge Ten Years LaterFormerly ExtremeProgrammingChallengeTen
StevenNewton writes: For example, the issue of what happens when a change breaks a test because of a seemingly unrelated piece of the code, and you no longer have anyone around who knows the "story" that piece of code is supposed to tell. What you get is what I've seen time and time again -- some program that worked for a while (maybe years) now fails, and no one around remembers the reason it was written the way it was, and someone tries to fix it and no know the original design or intent, can't solve the problem that causing the new failure without some other failure cropping up.
What happens to an XP project after ten years of constant change, both in the program and the team?
Can we answer the question with a question? Have you all seen cases where in-house developer documentation was ever satisfactory for solving this sort of problem? In practice, not theory. Moreover, if such documentation exists in front of you and you also have access to someone who has been with the system for a year, who do you go to first? Answer with your gut.
Sorry chaps, we already know the other methodologies mostly suck. You're just shifting the burden of proof. You say XP is grand, and we want to believe you. So many successful challenges down, this really ought to be a piece of cake. Come on, make like Xperts and knock this on the head.
I think our interlocutor above has missed the point of the exercise by not doing it. It wasn't a question, it was a thought experiment.
I'll venture a guess. (Yes, of course it's a guess ;-)
If XP was consistently and completely used throughout the ten years, you would have a healthy, flexible, well-factored system nicely meeting the needs of the customer (whatever they may have become). Throughout the ten years, the team would have continued following the value of Communication, bringing new team members up to speed and constantly tracking -- er, make that following ;-> -- the customers.
As I understand it, new people have come into C3. They were given some general, informal and verbal overviews and paired with different people. And they learned the system. My guess is that an outsider -- or another newer arrival -- would be hard pressed to identify the newcomer after a month or so.
-- KielHodges
Way to think, Kiel! --RonJeffries
Steven's question is, of course, heavily biased. It starts off with the presupposition that " you no longer have anyone around who knows the "story" that piece of code is supposed to tell. " So you cannot finesse his question by asserting that XP always will have someone around who knows the story, even if that is the intent of XP -- unless you answer, "Steve, XP properly done, that scenario cannot arise."
So my answer would have to be that the people on the project are trained to have written understandable code, and are trained to browse around the code to learn what it is doing. They have unit tests that check that it is doing it correctly...
Given the need of some people after 10 years to go into an old piece of code they don't know, they will browse around for a while, 2 of them. I would guess the would browse the UnitTests to see what they can learn from them. Then they will probably change something and watch the unit tests break, or refactor so they can try out their ideas, and watch the unit tests break. Then add their own, new, unit tests, change the code, and fix it up until all the old unit tests pass and all the new unit tests pass, and all the old and new functional tests pass, and then declare themselves done. -- AlistairCockburn
It seems to me that this says something interesting about UnitTests. I occasionally have an experience where I write some simple code using the 'obvious' organization. Then I run it and find one special case that invalidates that organization, so that I now have to reorganize the code into what looks like the second best structure unless you're aware of the special case.
This kind of thing always made me uneasy about people who say that you don't need to comment code: I tend to comment this kind of thing, to save the reader finding out about the special case the hard way. It occurs to me now that a better documentation (better because you can't avoid it) is a suitably pointed unit test.
-- DaveCleal
Yes! An interesting thing that happens is that when you are thinking about this kind of testing, you can often get in a frame of mind where you think of other corners that need testing as well. Sort of putting on your "black hat". (see SixHats?)
As an outsider looking in, it seems to me that, with all the refactoring that is constantly going on in an Xp project, whatever exact mapping initially exists between this piece of code and this UserStory should ultimately be fragmented. Or, rather, that any given UserStory would end up embodied in widely scattered pieces of code throughout the project. A FunctionalTest should, if my understanding is correct, always be in synch with a UserStory. But over the years even user stories are probably going to degrade (if XP is about change, and the systems it results in do change, a lot, so will the stories they tell).
A first question at this stage would be - to the actual XP practitioners - do actual XP projects exhibit this tendency ? If not, what happens instead, and what forces seem to contribute to the preservation, if any, of mappings from pieces of code to user stories ?
Even if the above observation is not correct, allow me to present a relevant parallel - XP as an analogue to genetics. I would expect that with the extreme emphasis on accumulated small incremental changes, whose effects on existing systems are 'filtered' first by the fine-grained sieve of UnitTests and further by the coarser-grained FunctionalTests, projets using XP should present behaviour similar to Darwinian evolution (large changes in organisms brought about by the accumulation of small mutations combined with the effect of natural selection).
This leads to a few specific predictions - such as the one that XP, in and of itself, will not necessarily prevent 'dead-end' products, by analogy with natural selection which is directional - it can't undo the changes it has wrought - and which can only result in "locally optimal" designs. You may reach a local optimum by following a given strategy, but this local optimum may be separated from another by a "gulf" of less-than-optimal solutions, such that the only way to improve is to start over from scratch. (See Richard Dawkins' books for a much better treatment than I could hope to provide.)
Conversely, a single bug should never be enough to bring down an entire XP project - in the analogy, an individual organism corresponds to a single integration attempt; it 'dies' if it doesn't pass all unit tests (or all functional tests). Bad mutations are never passed on. As with Darwinian evolution, there will always be a way to adapt to new requirements which are reasonably close to the existing system. In fact, it should be possible for two XP projects starting out with quite different requirements to end up similar in functionality, though with very different internal structure - as in convergent evolution. (This does happen in the 'real world', e.g. Userland's scripting tool Frontier morphing into a Web site management system with requirements similar to Wiki's; but it happens discontinuously, i.e. at some point you scrap the existing system and start from scratch, vowing this time, we're going to do it right.)
This analogy is perhaps not useful, and certainly only peripherally on-topic, but I'd like to see what actual XP practitioners think.
There should never be a case where there's no one around who knows what a story is for. If you do PairProgramming and CollectiveCodeOwnership correctly, the whole team will have knowledge of the task in short order, which means that it would take a complete team churn to lose this kind of information. Very pathological. However, in the event it does happen, do in order until a solution is found:
And if, after deletion, someone remembers and it is decided that the function needs to come back, then it becomes a new UserStory. -- KrisJohnson
Maybe try: write a test to find out what the code does before deleting it.
Getting back to the point raised: what happens when....
Maybe I'm missing something but isn't this a basic question about system documentation? Just because one's learning a method of DesignAndDevelopment? doesn't mean you drop all basic practices. Do write the final descriptive documents LAST. After coding, after changes, after refactoring. So the map is good. The question then becomes, either: how does one write good documentation; or what do you when you're on a parachute drop and the system is totally undocumented. Good questions though these are, I don't see how they relate to the topic.
Am I missing something here? Please clue me in if so.
In addition to functional/conceptual/tutuorial type documentation, API docs should be produced: automatically whenever possible (e.g., JavaDoc in Java). Plus if you own the code, you can read the source. I have NEVER heard of a methodology saying: get rid of basic good programming habit and style and never comment your code again. Just the opposite - these methodologies all build on basic good programming habits. And languages are starting to encourage it too: Java for one is very nice about encouraging good in-code comments: you get free API docs that way; not to mention naming conventions, etc. That answers one of the questions: don't put yourself or other coders in the dark: write documentation.
-- EzraEpstein
EditText of this page
(last edited February 27, 2003)
or FindPage with title or text search