Plea For Xp Code Example

Can someone please show an example of a substantial system written using XP? There are a lot of claims made about the code produced using XP yet i have not seen a single example after asking many times. The Unit test framework is not substantial and InMyHumbleOpinion is not very clear at all.

If you're actually looking for an XP code example, don't look on this page. The best suggestion in this regard just might happen to be this : read up on XP, then write some code according to its principles. After which, decide whether the claims made about XP code are correct or not.

Look at ExtremeProgrammingProjects, or read about WhosWritingAboutXp.

ExtremeProgrammingInPractice http://www.amazon.com/exec/obidos/ASIN/0201709376/ / ISBN 0201709376 / http://www.awlonline.com/product/0,2627,0201709376,00.html

XPIP is a whole book coming out soon showing an XP project that ObjectMentor did, the good and the bad. It shows some really nice code coming out, it shows what happens when you change out all the programmers on a project, and it's as true as the authors could make it, warts and all. I don't know what it will convince people of, but it has the whole program in it. -- RonJeffries

It is going to be a little harder to show a "substantial system" because most people take "substantial" to mean "big." I find that XP projects have less code because of the principle of DoTheSimplestThingThatCouldPossiblyWork. If you include test cases, which most projects don't have, then the sizes are comparable. -- JasonBedunah

Same sort of response I get when I ask vitamin salespeople or faith healers for some evidence. XP projects may have less code, but they have code for god's sake so let's see some!

There are small code examples in XP Installed, what is your assessment of them?

XP claims you don't need documentation because refactoring, selecting names properly, and unit tests make it unnecessary. This is a testable claim. If you can't tell by looking at XP code then XP is pointless. The process should produce something identifiably different than "ordinary" code. And if you actually studied artifacts i believe you should be able to tell a great deal about the process used to create it. But without artificats the point is moot. For example, code that uses "a" as an identifier would be produced by a different thought process than one that usedidentifiersthatwereverydescriptive. Likewise, code with extensive unit tests. Likewise, code with many smaller classes and methods.

Sorry, but that's not what we claim. The advice is that when you feel that the code needs documentation, you should first take it as evidence that the code needs to be more clear. When you've done your best with the code, then document what still needs it. In all cases, you need to use your own judgment, or that of someone with better judgment, as to what your team needs documented and how. We think it'll be less than you might imagine.

In any case, what really matters is how communicative your code can be, not how good someone else's can be. Some projects can surely make do with very little non-code documentation. Some surely cannot. Yours ... is yours.

-- RonJeffries

I've been in numerous conversations with XP'ers about documentation and the line has always been hard about the code is the design and it is self documenting. If it's not then there is something wrong with your code. Make more better name classes and methods, remove code, etc. It was not advice. It was an assertion about how properly written code does not need documentation. So i'm sorry. You may when pressed think there's a softer side to XP, but in conversations people tend to be very hard line. -- AnonymousDonor

Is documentation "one size fits all?" XP says that design documents are not necessary (but are OK techniques, if you want to explore some ideas before coding) for producing a design and implementation, that "listening to the code" and refactoring can produce a design that is probably better than you'd get by doing all the design prior to coding. XP says that design documents are not necessary for communicating within a close-knit team; that verbal communications are quicker and less error-prone. XP does not say how you record the design for posterity; that's where, if this is important to you, you should produce your design documentation. -- GeorgeDinwiddie

The best proof would be from a largish project so we could see if it is possible. I think the XP techniques can make better code, I don't believe at all that they take the place of comments and documents. Rather than argue endlessly i'd like to see an example to judge for myself. Perhaps my standards are different than other peoples. Perhaps i'm wrong. But evidence is lacking.

I'm aware of no XP project, other than the XPIP book, that is in a position to publish its code. Most XP projects are software for pay and don't publish their code. Posting this request on the extremeprogramming group at yahoo.com might get a reply. It would also generate about 50-100 emails a day while you wait for a reply, so caveat emailer. But again, if you're looking for proof that no project needs documentation, that's not what we claim, and not what we're trying to prove. -- rj

I may be totally off base here, but how does looking at code give you any idea about the process that generated it? I could write a whole bunch of really clean code using a BigDesignUpFront methodology and you could take that and "prove" XP. Or I could use XP to make a bunch of "un-publishable" code and you could take that and "dis-prove" XP. I still fail to see how the artifact produced says anything major about the process used to create it.

I am referring specifically to the fact that I have, over the past several years, produced a lot of clean and (InMyHumbleOpinion) readable code. I only "discovered" XP about a year and a half or so ago. Does this mean that my old code is worthless? Or does it mean that XP is one way to produce good code? If It is one way then I could send the original poster any code I have written in the recent past and "pass it off" as XP code. The only thing I don't have in older code is UnitTests. While this may reduce the "testable robustness" of my code, I maintain it doesn't actually affect the quality or readability of the code.

-- IainLowe

Except that I agree it would be nice to have a large example of the work products of XP, and that includes everything, not just the code. -- SunirShah

In some cases it's quite unambiguous. I have had great success on many projects with a framework approach and have rarely if ever suffered from bigdesignupfront. Yet i'm told frameworks are bad because some XP guy cocked-up a database framework once. [RudenessObjection?]

: We say there are risks with frameworks, such as building too much stuff, and building stuff that doesn't work well for the next apps. We say that it's better to draw frameworks out of apps by refactoring. What part of this do you disagree with? Please make a new page or use an existing framework page.

I say the naming i've seen doesn't provide enough context and nuance. Yet i'm told names can subsume all meaning.

: I can't find any place in the XP writings where we say this. Perhaps you are reading something in that isn't there?

I've had very good luck writing documentation for a class first. Yet i'm told you must write unit tests first.

: In XP, we write unit tests first. Actually one test, then some code, then another test, etc. We don't say you must do it, we say that if you're doing XP that's what you're probably doing.

On largish project it's very hard to get people to change existing practice or code. Yet I'm told refactoring has little cost.

: Yes, it is hard to get people to do it. And it is also true that if the team does it, things go better, and costs stay low.

And so on. Almost everything I have had success with i'm told didn't really work and can't work and there's only one other way to do it.

: No XPer would tell you that what worked for you didn't work. We would not tell you there is only one way. If you like doing what you did, you should IMO continue. If there were things you didn't like, try something different, from XP or elsewhere.

And when I ask for one bloody example, I'm told like most religions to just try it, no it's not odd we can't give you an example, just believe. [RudenessObjection?]

We are here to try to explain what the XP way is. The XPIP book will be somewhat of an example, though as I say I'm not sure that it will answer your question, since your question may be founded on some misconceptions. It would be nice if there were other examples, but there aren't many.

But the fact remains that code I write should not be the final answer for you. What readers need to do, examples and text notwithstanding, is take what they read about, hear about, think about, and adjust their practices in an experimental way, continuously finding what's best for them. I don't know what's best for you. I know some things you might want to try.

Would the OP please begin a CritiqueOfJunit?, since it's the one example that's widely available?

I don't know junit, but did start with CppUnit. It's a very small system, so it barely qualifies as an example. Four people in our group tried to use it; none were able to understand without my help. And the only reason I understood it was because I had to rewrite a lot of it for our pathetic compiler on an embedded platform. I found it very hard to understand how to actually do anything. This would be fine normally, but given the attitude of XP partisans, I found it somewhat of a let down.

By the way, CppUnit has some nasty memory leaks in it.

CppUnit was written by one individual, in an attempt to replicate the functionality of jUnit and sUnit. I don't think he would propose it as an example of XP code. Write and ask him.

But what would be the value of an XpCodeExample?? The claims I hear being made is that the XP code is clear and easy to understand for the team, and that a member of the team can easily explain it to someone else. I've never heard the claim that someone else could pick this code up without assistance. After all, the code expresses the detailed domain concepts and without that background any outsider is going to spend time getting to know the domain. -- PeteMcBreen

I believe the response would be to select better names and refactor and you can encode the domain concepts such that documentation or a human interpreter is not needed.

The response would be to do that, and then to write up whatever else needs to be, or record it on video or some other non-code medium. -- RonJeffries

It may sound like whining, but I would love to see an example of XP development that does not apply to Web sites, databases, payroll systems - you know, that "businessy" stuff. There's a whole bunch of us out here doing more hardware-oriented/embedded/scientific sort of work, that maybe could use an example more applicable to our line of work to help XP "hit home". -- MikeSmith

Here is a code sample that does not put a single packet onto the Internet, does not store a single byte of data persistently, and most definitely does not result in any single person getting paid even a single penny, not even the author of the software:

http://zipcon.net/~showell/cgi-bin/Karel/FolderPiki.py

If you like this code, then consider it an endorsement of XP's TestFirstDesign principle (which I used). If you dislike this code, consider it a warning of what can happen when you ignore XP's PairProgramming recommendations (it was done solo).

I am working on another XP project where we are rewriting an editor in Python. I think on non-businessy applications, you can use a lot of the code-oriented practices (unit testing, pair programming, constant refactoring) effectively, but the more customer-oriented practices (onsite customer, for example) might not be quite as compelling. Small iterations do help, though, even if you're your own customer. -- SteveHowell

(How should an XP example be presented? To see the world through the masters' eyes, the students must re-live the evolutionary process. In how much detail and in what data structure should the development history be recorded?)

The code stands alone. It's evolution doesn't matter. Just show the code. -- AnonymousDonor

The code isn't the only thing that matters. Code doesn't happen without context. Who's looking after that code? How is knowledge about that code passed on? Is this code what the client needs? None of these can be definitely answered from looking at the source itself.

The success of any process depends on lots of things that are not immediately visible in the code itself. In fact, since XP depends on interpersonal communication so much, such a way of looking is guaranteed to give a slanted view of the process. I'm reminded of the Western disdain for more "primitive" social systems - microcredit in Korea and India, consensual justice systems in Native American communities - because much of the wisdom in the system is passed down verbally, and therefore it's unaccessible to outsiders.

Yes, this can make XP sound like a cult. And it can make it very difficult to analyze XP from a safe distance. But what good is that safe distance anyway? I hate reading other people's code anyway - I always find it easier to learn from doing. When I first got interested in this stuff, I started to program my own mini-project with UnitTests and RefactorMercilessly, and learned a lot that way. Then I was lucky enough to find other people who were starting a local XP study group (XpNewYorkCity) and we get together and program an XP-style project for 2-3 hours a week, and that teaches me a lot about PairProgramming and StandUpMeetings?. I haven't consulted the books very much, but I've learned quite a bit.

"Code doesn't happen without context."

It will be obvious if the code is screechingly obvious and has all the other properties XP says it will. Requiring a filter before you look at anything does sound very cult like. -- AnonymousDonor

And yet all the stuff about ScreechinglyObviousCode and SelfDocumentingCode and whatever else is largely outside the core practices about XP. I don't remember reading anything about SelfDocumentingCode in XpXec?, for example. I remember reading lots and lots of stuff about process, and about how people should relate to other people.

Maybe people learn differently. I always get impatient when I'm just reading other people's testimonials, code, what-have-you. I want people to give me their secrets and then get out of my way so I can try them out for myself. The XP core practices aren't difficult to understand, and you don't have to pay tuition to try them out. Are you so busy that you can't devote some of your spare time to seeing for yourself?

Self documenting code has always been central to XP which is why I asked to see some so I could evaluate what they consider self documenting. I have never seen any code like that nor have I been able to produce any. Rather than argue if the earth is flat or not let's go explore and see. Same way with the code. Show me the code in the large that is self documenting so we can stop arguing over it. -- AnonymousDonor

What is that makes it seem to you that "Self documenting code has always been central to XP"? I looked here on ExtremeProgramming, ExtremeProgrammingRoadmap, and ExtremeProgrammingCorePractices, and I haven't been able to find any mention of SelfDocumentingCode. Could you cite where you're seeing this?

In ten gazillion discussions on documentation policies. The assertion is that you don't need to document because you can structure code and use identifiers such that very little documentation is necessary. If the policy is to say very little documentation should be necessary, that means SelfDocumentingCode, regardless of the words used. -- AnonymousDonor

I would say that many of the people who are interested in ExtremeProgramming are also interested in the idea of SelfDocumentingCode. But when I look at the core pages, I find nothing to support the claim that, as you put it, "Self documenting code has always been central to XP." This isn't a semantics issue; I honestly can't find this centrality you're referring to.

A core contention of XP is that code ownership is not necessary. That teams can flit and change. That any team can work on any part of the app. A core contention of XP is that pair programming is efficient, and that the teams do not get swamped by the learning curve when they start modifying some new, previously unseen part of the application.

Some doubters regard these claims as impossible. These doubters, have seen the code in their own repositories and shudder at the thought of two random programmers from the team walking into some parts of the code base where domain knowledge is thick and rampant. These doubters wonder how code produced by an XP process can be any different. They ask to see. They are not answered. They are told instead try it.

By this point on this page I expect many doubters may be wondering if XP produces any code at all.

Note: I am NOT a doubter. I know what XP practices can do for me. I know what XP practices have not done for me.

On some projects, code will need extensive documentation. I doubt I would write a galaxy simulator (many body gravity) without some real documents and equations, that were completely outside the code base. While some of the equations F = Gm1m2/r^2 are akin to user stories, the equation explaining how I will handle rounding error so that it does not become systematic will require pictures and other stuff that are not user stories.

On some projects, code will need little documentation apart from the user stories, the acceptance tests and the like.

On some projects, if they are large, the application will have an architecture that is built according to system metaphor. This high level picture will draw boxes each representing many KLOC. A picture at this level is not seen by reading the code no matter how readable it is. XP needs documentation for large projects.

On a big project, I can see myself designing high level structures and collecting user stories until I reach a point where I believe the system metaphor is fleshed out and stable and the modules are small enough where individual programmers or team leaders, think (confidently) 'I can build that bit'. To be confident they need also to be sure that they can build it and absorb the as yet undefined details as they are resolved. The group also has to be confident it can build its first deliverable from here. Building the first deliverable acquiring more user stories getting more customer time on site and the customers reaction to the first deliverable is what defines where, when, and what the second deliverable is.

Now I don't have any code to show either. This is for two reasons, I have never made anything using enough of the XP practices for me to dare to call what I have done XP. The fact that no one else has any code either worries me. Are the, 'real' (rj etal) XP people here saying that no open source project has taken XP on as its development paradigm? If so I am worried about XP and fear I have misjudged its credibility.

-- confused

I would imagine that one major reason that XP is not used in OpenSource projects is that they tend to be geographically distributed, which makes practices like PairProgramming and StandUpMeeting difficult. -- MikeSmith

see FractalLifeEngine, ExtremeProgrammingExample.

Try this: http://www.perl.com/pub/a/2003/10/09/refactoring.html -- ThomasTuttle?