View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007

Fall01 Final Exam Review: XP

Back to Final Exam Review - Fall2001


1) The idea is that the code will be refactored into an form that is easy to read. Since the code is not owned by one person it will have to be viewed by multiple people, meaning many people will have a chance to change it into an easier to understand form. Joaquin Madruga

2) ALl programming should be done in pairs. According to XP guru's this produces higher quality code with the same (or even less) labor costs. Joaquin Madruga

3) Since there is no code ownership, you can change anybody's code to make integration work. Also, continual integration prevents the big bang style of integration. Stand up meetings and a close environment help programmers resolve interface issues. Joaquin Madruga

4) Yes there has been one study on students that forced half the class to do pair work. At first the paired up students took longer (the adjustment period). However, by the end of the class the code produced was higher quality and took less time. Joaquin Madruga

1, 2, and 3 are all partially right, but missing some critical pieces. Mark Guzdial


1) All of programming in XP is done in pairs. One person writes the code while the other looks over their shoulder and reads it. If the code is unreadable to the person watching then it will be changed to something that is easily understandable.
2) Coding is done in pairs in XP to ensure readability and quality. Thus any code that is written by an individual doesn't have that second person checking over their shoulder which lessens the quality and readability of the code so it is subsequently thrown out.
3) Since everybody owns the entire code base, integration isn't as big of a hassle as it is under other systems. Also with XP all modules have predefined test cases to ensure their quality. Code may not be put back into the active project until it is integrated AND passes all of the test cases. A way to make it go more smoothly would be to use revision control systems that suppor this idea of global ownership(CVS!!!)
4) There was a study done by a professor on this subject. She had half of the class program normally on all of the project and the other half was required to do XP style coding. At first the normal students performed much better but in later projects they were superceded by the XP people( more quality, less time)
Jared Parsons

1) What proceeds is correct, but incomplete. XP discouraging coder comments is a myth. Why? Because XP believes code to be the purest form of documentation there is, and shuns all non-code related documentation (design documents, formal specification) except the user stories, and documentation in the code itself. Documentation directly in the code constantly has eyes on it and is being tested, coded, and refactored as the system progresses. Sort of harkens back to Knuth's Literate Programming idea. Since there is no other documentation in XP, every non-code observation about the system's works must be written in code comments; and coupled closely to the code. Graham Coleman

2) Each code must be written and rewritten until two people understand it. This naturally (and hopefully) forces most code to at least a common elegance, in operation and in clarity. Then, that code has two parents... two people thinking and coming up with more compact solutions, brilliant refactors, and simpler, more maintainable code altogether. Graham Coleman

3) Integration, when implemented in a daily, iterative approach, uses more time in the beginning when everybody adjusts to the cycle, but saves time and trouble when the product is actually needed. This approach was needed because of the sheer number of bugs integration alone (interface inconsistancies, overall flow) tends to insert into software projects. Graham Coleman

Nice! BTW, Jared, the study was done by a Ph.D. student, who's now a professor. There may be more empirical evidence out on the XP sites. Mark Guzdial

Another important part of part 1 is the shared knowledge of the code. You work in pairs so that you have two people that understand it well, but that pair only last for a day or so, then you rotate to get new people looking at the code, so after a while, everybody there has a very good understand of the code. that combined with the refactoring and everything else mentioned above could be very effective.

Jason Fulghum
I was under the impression that pairs were switched closer to an hourly basis. I am wrong about this?
Robert Schierholz
an hour kinda seems like a bit much. I think it's probably more determined by the task they are working on rather than any specific time. I assumed people would pair up for a task and then work on it until it is completed, then go get another task adn possibly regroup with different partners

Jason Fulghum

I believe I read somewhere between cs2335 and 2340 notes that pairs generally change every 2-4 weeks, this is only a guideline though...Besides, it really wouldn't make sense to switch every hour or so. The learning curve would be crazy! It's important to 'share' the code, but not to that extreme.EW Looney


Link to this Page