Have you had experience using the XP approach to building software? If so, what are the pros and cons from your perspective?
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 31 of 31.

• XP=eXpress Prototype ?
  2003-02-27 14:18:56  anonymous2 [Reply | View]
  
  
  From what I read, the main idea is to deploy a Prototype to production as quickly as possible. And let the user hit the bomb as early as possible, as often as possible. Been there done that. But we call it 'quick and dirty', 10 years ago, which interrupted our Director and Manager's career. It may work for certain projects in certain shops. I seriously doubt it will be accepted in many places, perhaps until it is renamed to 'eXpress Prototype' :-).
  
• XP=eXpress Prototype ?
  2003-05-15 07:33:42  anonymous2 [Reply | View]
  
  
  It is obvious from your reply that you may be one of those people who have opinions on everything.
  
  ie. "I'm not familiar with that technology but I if my estimates are correct you might need to call function X to invoke output Y..."
  
  XP is about evolutionary development. While prototype deployment is really fast coding to implement a feature, XP has certain techniques that allows for programmers to extend and refactor earlier code (the author was not clear on these).
  
  Plus little bits of chaos injects fun into the workplace. :)

• What about documentation?
  2003-01-28 12:33:30  anonymous2 [Reply | View]
  
  
  
  Does anyone have experience producing effective documentation in this type of development environment? It sounds like it would be hard on the writers. Or is there a way to manage it?
  
  Thanks!
• How I can Make XP documentation?
  2004-12-01 03:47:40  qasem1 [Reply | View]
  
  
  Please, if you can tell me of how I can buid an XP documentation. and it can be done by making documentation for each phase (plane, design, code and test) or all in one documentation?
  
  Thank you very much
• What about documentation?
  2003-10-21 02:25:02  anonymous2 [Reply | View]
  
  
  Documentation is *always* hard on the writer, just as programming is. But it can be fun, just as programming can.
  
  I'm not doing XP but I've done something that looked suspicously like quick-and-dirty that had to be tested by someone a long way away who didn't fully understand what I had produced. During development I circulated specifications in the classical manner, and had them not read and not signed off also in the classical manner.
  
  For my tester, who was in much the same position of ignorance as a real user, I had to write a whole load more text to explain how to use the system so he could test it. Hurrah! A user manual, though not presented as such, and not nearly complete. Still, it truly reflected the softrware because it was written alongside the development, slightly lagging.
  
  I'd suggest doing two things. First ask: who's going to read this and what do they want out of it? (Be honest, which bits of the documentation for "closed" projects do *you* read?) Second, treat those documents that you still want to produce as part of the development. Deliver them along with the code, get them accepted by the customer (or not).
  
  Thirdly (out of two?) get the documentation tested. Find some poor fellow who doesn't know the system and get them to try using it taking your document as guidance. Watch them try to get help on a topic where they don't know the keyword. Hear them snore over the contents list. Demand honest feedback. Good luck!
• What about documentation?
  2003-04-22 06:13:04  anonymous2 [Reply | View]
  
  
  The approach to documentation is both pragmatic and scary.
  
  - Only do the documentation that adds value:
  - Since documentation external to code tends to drift relative to code, document as much as possible within the code.
  
  The first point is scary since it is hard to asses documentation value while in the midst of the development frenzy that XP supports. The second is achievable for internals documentation using tools like .e.g. doxygen.
  The piece of the pragmatic approach I like is the recognition that diagramming and other modelling techniques are just that: modelling techniques: Modelling should be done to enhance or communicate understanding.
  Modelling to the 'bitter end' serves no function except to support 'round-trip' model <--> code, and I have never seen systems that support this that can take a cycle through that and leave you with understandable diagrams.
  So I think it's a good thing to question the usefulness of the documentation we have been trained to produce compared with the value added to the system in terms of understandability and maintainability, but a danger that this value will be mis-evaluated in the rush to meet that release goal.

• XP in Web Development
  2002-12-03 04:54:20  anonymous2 [Reply | View]
  
  
  Has any one applied XP to the Web Development/Design process. I would be interested in sharing in the experiences and lessons learnt.

• about extreme programming
  2001-11-24 22:30:35  dba [Reply | View]
  
  
  hi,
  I'm a student of University Technology of Malaysia in Johor .I really attract with Extreme Programming technique ,but my knowledge about it still not enough and here, I hope you'll sent me the details about extreme programming. I'll always appreciate your co-operation. Thank you.
• about extreme programming
  2003-02-16 14:42:34  a.bilal [Reply | View]
  
  
  Hi i am a student of Masters in Software engineering in university of hertfordshire.
  now a days am working on extreme programming, i am thinking to do my masters project on COMPREHENSION RISKS IN EXTREME PROGRAMMING.
  i have found that extreme programming will be a big picture on the face of tomorrow in the world of programming.
  if any one wants to share his/her views on COMPREHENSION RISKS IN EXTREME PROGRAMMING plz contact me .

• about extreme programming
  2001-11-24 22:16:31  dba [Reply | View]
  
  
  hi,
  I'm a student of University Science of Malaysia in Penang .I really attract with Extreme Programming technique ,but my knowledge about it still not enough and here, I hope you'll sent me the details about extreme programming. I'll always appreciate your co-operation. Thank you.
• about extreme programming
  2007-02-22 21:48:00  teayu [Reply | View]
  
  
  hi dba, which language do you program with? We're an MSC startup in Penang and are hiring programmers actively for our patent-pending e-book platform. We're leveraging some of the best development practice like Test-driven development, Spring IoC and MVC, pom, etc.
  
  do drop me an email if you're interested, tea.yu <at> summation.hk

• Extreme
  2001-06-28 11:06:39  mvr707 [Reply | View]
  
  
  The article has a "feel good" touch about it:)
  Its nice...
  
  But what is different?
  
  Water-fall:
  Requirements->Design->Code->Test->Ship
  
  Spiral model:
  R1->D1->C1->T1->S1 Get Feedback
  R2->D2->C2->T2->S2 Get Feedback ... and so on...
  
  So whats so different in Extreme?
• Extreme
  2001-06-28 11:21:11  mvr707 [Reply | View]
  
  
  There is something called "Spiral Delta Model"
  This is waterfall folded in the middle and spiralled (Iterated).
  
  RS: Requirements Spec
  FS: Functional Spec
  D: Design
  C: Coding
  UT(P): Unit Test (Plan)
  IT(P): Integration Test (Plan)
  ST(P): System Test (Plan)
  AT (P): Acceptance Test (Plan)
  
  Waterfall:
  RS->FS->D->C->UT->IT->ST->AT
  
  Convert that to a Delta shape with iterations
  
  (RS,ATP)->(FS,STP)->(D,STP)->(C,UTP)->UT->IT->ST->AT
  
  This is a tight Delta Spiral. And after a few
  cycles, we hopefully hit the bulls eye!:)
  
  As we know, different models are appropriate for
  different stuations. So what are the salient differences of Extreme Prog and when is is appropriate?
  
  The article makes good reading but leave hugh and dry
• Extreme
  2001-07-14 18:08:33  chromatic [Reply | View]
  
  
  The biggest visible differences are that iterations are very short in XP, and that programmers can often go through most of the different stages multiple times in a week. (There may be one relatively large story and task planning session and one acceptance test session per iteration, but most of the rest of the stages are done at least once per day.)
  
  The best way to look at XP is as something that keeps the cost of change very low. There's not a lot explicitly invested in the future. This fits in jobs where the specs can change quickly, or where a job can be delivered in stages, one every six weeks or so.
  
  It's probably not a good fit for defense contractors, and large shrink-wrap software houses might have a hard time adopting it. For situations that require a lot of flexibility with short notice, it can be very useful.

• XP - MSF?
  2001-06-11 21:09:55  stevehayr [Reply | View]
  
  
  Extreme programming isn't nearly as extreme as the name suggests... I've been using MSF for about 8 years now and from what I can see, the only difference is that MSF suggests teaming a tester with a developer rather than another developer (the tester should be technical enough to read code). To me, this seems far more sensible... and not nearly as costly. Mostly extreme programming seems to be more about the language the ideas are conveyed in rather than the practices used. Has anyone compared the MSF approach to Extreme?? I would suggest that projects run using MSF would be as quick to develop (and cheaper)...

• Everything old is new again.
  2001-05-15 12:49:02  Michael Schwern [Reply | View]
  
  
  My first impressions of XP was "This is nothing new". It is 'extreme' only in its proposition to use Best Practices all the time. And I too fixated on the apparent idea that you don't have to do up front design.
  
  But there's something you must remember. While its been rather clear for quite some time what makes up a good software project (at the very least since the publishing of Mythical Man-Month in 1975) we continue, collectively, to ignore it. The state of software engineering in the workplace remains as piss-poor as ever and large percentages of projects overrun their schedules.
  
  In short, we, as a field, suck, compared to say mechanical engineering.
  
  So while to someone clued into software engineering, XP might not seem so extreme, when held up against the state of current practice, its very extreme. Taken in this context, it makes a bit more sense.
  
  XP isn't saying "You don't have to design up-front" its saying "You don't have to design up-front as much as the usual Waterfall model says you do." (Waterfall being the typical practice of linear development: requirements, design, code, test, release. Most use it without realizing it.). XP is very similar to the old Spiral Development plan, just with tighter spirals.
  
  But to many people this is all brand-new! Or if not brand-new, its unpracticed. The clumsy Waterfall model is still in very wide-use. Quality is constantly chucked under pressure. And the 40-hour week seems like an unachievable dream for none but the "gurus".
  
  XP is extreme in that the current practices are lacking, not that better ones aren't already available. Its new only in that people are unaware/ignoring what's been known for so long.

• My Experience
  2001-05-14 17:17:51  chromatic [Reply | View]
  
  
  As several other posters have mentioned, there's plenty of anecdotal evidence that XP (and XP-like practices) have improved efficency.
  
  Just in the last couple of weeks, I was adding some loosely defined behavior to a system. I knew what it had to do, but I didn't know how to implement it. I wrote a handful of unit tests first, which forced me to think about the API I was about to create. It took maybe 20 minutes to get the tests into shape.
  
  Fifteen minutes after that, they all passed. Writing and debugging the actual code was extremely easy, once I had test in place.
  
  If I'd had a better spec in place, it's entirely possible that I could have written the code without the tests -- but I'm almost never that lucky.
  
  Maybe there are development shops out there that don't need to read 'The Mythical Man Month' and 'Peopleware' over and over again. For the rest of us, I'm pretty happy someone's pointed out that combining several of the practices everyone has known are worth doing for years has unintended and beneficial consequences.

• Yeah, but where are the *interesting* comparisons?
  2001-05-14 15:15:21  gvwilson [Reply | View]
  
  
  The study by Williams et. al. concludes that two programmers working together can accomplish something with slightly less than twice the effort as one individual programmer. I have a hard time getting very excited about that conclusion. What I'd like to see is a comparison between pair programming and inspections, or 3 pairs vs. 1 well-run 6-person team. Until I see that kind of data, I'm going to continue to believe that most programmers who pick up XP do so as a way of legitimizing their existing poor practices.
  

• Just a couple note on continual improvement.
  2001-05-11 09:10:00  richkatz [Reply | View]
  
  
  This seems to slip by slightly in the article.
  
  XP has (at least) one organized body of information
  on continual improvement called "Refactoring."
  
  You can accept that there is one and only one
  true "refactoring"
  
  Or you can chose to disagree with aspects of this
  body of knowledge, seek to improve it, or maybe
  substitute a new body of knowledge, but still
  continual improvement needs to be emphasized as
  it is part of the trade-off involved in not doing
  the big design.
  
  But in either case, don't both programmers need
  to at least accept the goals of refactoring to be
  able to work together?
  
  
  
  

• My XP experiance
  2001-05-11 07:14:50  michaelfurman [Reply | View]
  
  
  It was very exiting for me to read this article -
  I am doing XP (and sometimes fighting for it)
  almost all my professional life - close to
  30 years - in many different areas. And every
  time it helped to make software faster and better.
  Starting development early in parallel with
  design not just saving time. It also:
  - helps to find some design errors/problems
  earlier,
  - serves as a proof that design decisions can
  be implemented,
  - help create demos and prototypes with minimum
  additional cost.
  Working in pairs is also very helpful - though I
  almost did not have this opportunity
  since I moved to the USA.
  
  Michael Furman
  
  

• my experiences as an extreme programmer.
  2001-05-10 13:56:32  traderjones [Reply | View]
  
  
  My first reaction was a chuckle. I've been doing this for 13 years. I've written business applications for pharmacies, youth sports organizations, in the healthcare industry and other commercial ventures. The Extreme Programming model is by far the most flexible and productive method.
  
  XP takes the traditional practices taught by the 'computer scientists' and makes them useful in the real world.
  
  Customers don't always know what they want, and XP allows the project to flex as the customer gets a clearer definition of what really is important for their system.
  
  Reducing the front-end design process and folding it into the development cycle saves time and money in the long run as useless features are not implemented and new useful features can be added to the process without starting over.
  
  Working with a second programmer is (for me) a productivity booster. Not every programmer does things the same way, a major roadblock for one person may have a simple solution produced by another. There is a certain synergy that happens when true XP programmers get together.
  
  I now work for an extremely successful Independant Physcians Association. When the time came to buy an update to our software we had the choice of spending hundreds of thousands (or millions) of dollars on a new off-the-shelf software for claims and referral management, or develop our own. We choose the later using the XP process with positive results. Two major (national) insurance companies have been forced to pull out of our market because they couldn't make it financially. We absorbed their market and are still showing as one of the most successful organizations in our state. The XP model allows us to move with the market as the healthcare industry moves away from the HMO model and into it's next methodology. Without XP we would be looking for another off-the-shelf package to handle the changes, with XP we adapt, grow and move with the market.
  
  

• XP User Groups?
  2001-05-10 12:26:19  aviggio [Reply | View]
  
  
  I started an XP user group (www.xpdenver.org) last August for the Denver area and now have over 200 members. Is there an XP user group in your area?
  
  Also, I recommend visiting http://agilealliance.org/, where XP thought leaders have joined with other principals of the Agile Software Development movement.
  
  - Alex

• XP in a classroom
  2001-05-10 10:32:51  slimick [Reply | View]
  
  
  I used XP in the Software Engineering course this
  spring. Well, I tried. I did have very positive
  results. Of my four groups ALL had functioning,
  useful code at the end (something I've never had
  before). The things that worked best:
  - Defining stories;
  - Picking stories for V1.0 (I had a drop dead
  date of March 1 -- there was no grumbling
  about too soon or an unfair target.)
  - Having acceptance tests available a week before
  both deadlines (V1 - 3/1; V2 - 4/17)
  - In the group where all the students were at
  the same level of ability, pair programming
  worked well.
  - By having simple stories, people could use
  simple designs.
  Things that didn't go right:
  - The other groups consisting of an obvious
  master programmer plus novices
  did not use
  pair programming. Apparently the novices
  were overwhelmed by the master.
  - I didn't do enough on having the groups write
  unit tests before they started programming.
  Things would have worked better if I had done
  so.
  - Apart from one group there seemed to be little
  sense of ownership.
  - Had the semester been longer, there would have
  more refactoring -- some had already started.
  
  One factor in looking at our results is that this
  is not a residential 4 year school -- one group
  had a residential CS major, another residential
  CS major who was on the women's basketball team,
  and a third who lived 50 miles away and
  depended on others for transportation, since he
  has a medical disability that does not allow him
  to drive.
  
  In the past most of what I got from the Software
  Engineering course were promises, excuses, and
  software that barely compiled. I intend to use
  XP next time (Spring 2003) when I have this
  course again.
  
  John Slimick
  University of Pittsburgh at Bradford
  Bradford PA 16701
  slimick@pitt.edu

• Evidence
  2001-05-10 08:03:02  johansi [Reply | View]
  
  
  Check out the following PDF for some empirical evidence of the benefits of Pair Programming (one of the practices of XP): http://www.objectmentor.com/s4williams.lo.pdf
  

• Evidence?
  2001-05-10 07:32:46  jamesm1 [Reply | View]
  
  
  Chromatic,
  
  Can you provide any emperical evidence to support claims such as:
  "Extreme Programming (XP) improves the efficiency of writing software." ?
  
  

• A paradigm shift, or something more trivial ?
  2001-05-10 05:23:01  froogle [Reply | View]
  
  
  eXtreme Programming is, as others on this forum have quite rightly pointed out, nothing new. The concepts and principles it embodies have been around for years. The concept is eXtreme simply from the point of view of it advocating code, code, code, instead of locking the developers into the traditional mire of paper and beauracracy.
  
  The key with XP though, as with any other process out there, is not to either accept or whole-heartedly reject everything it says on a whim. Processes are principles, guidelines to follow. Consider them a map of the highlights of some exotic city you plan to visit. Do you throw your entire holiday behind one guidebook, or choose the best bits of a number of them?
  
  eXtreme Programming can add value to projects where little or no process already exists. eXtreme Programming can also add a great deal of value to projects where the process in place is failing badly.
  
  Better yet though, pieces of eXtreme Programming can be mixed and matched with pieces of other processes. Choose the parts that suit you, then go ahead do the same with FDD (Feature Driven Development), Steve McConnell's Best Practice lists and so on.
  
  No one practice is suitable for everyone out there. Mix and match them and build your own. At no point though should any of us be pulled along on some religious crusade to adopt the latest and brightest invention of the coding process gurus.
  
  Just my two cents. ;)
  
  Peter Wright
  Author, and founder of HashBang
  www.thehashbang.com
  

• Lovely idea but...
  2001-05-09 13:06:12  qzjsrb [Reply | View]
  
  
  Customer runs acceptance tests.
  
  Now here we have the problem... for large software systems the user doesn't WANT to keep receiving updates over and over again. Some systems you'll be lucky if they will take two releases a year from you, now matter how much you want to deliver the super-whizzy extra that will make all the difference to them. It costs customers to take software, test it, train the users, upgrade the software, iron out any new bugs...
  
  Most users would prefer to specify requirements way in advance and then bitch 'cos they've changed their mind by time you deliver it. If you want to use XP you need to persuade the customer before the programmer...

• Duh, part 2
  2001-05-09 09:20:34  toddbradley1 [Reply | View]
  
  
  Maybe I'm just not enough of a fossil, but this approach to software development isn't really anything new. When the author compares XP to "traditional" development, it sounds like he is using "traditional" to mean "the way it was done in the 60s and 70s".
  
  Writing one feature at a time, writing a test for each function, doing code reviews, releasing early and often were all the way I learned to make software back in the late-80's. So, I guess it doesn't seem "extreme" to me. This is just the way things are done on good commercial software teams for at least the past 10 or 15 years.

• Duhhh? Is there more to programming than writing code?
  2001-05-07 08:01:01  pivot [Reply | View]
  
  
  "You shall sit two together to code!
  
  You shall not think (design) before programming!
  
  You shall design the code to be tested!"
  
  Is there something wrong with this picture?
  
  Are these people just now realizing that there is more to programming than just writing code?
  
  To me, "extreme programming" only seem to mean that there are people with "extreme" views.
  
  Programming has allways been a field where experience is vital, and experience doesn't come from rules.
  

• Why "Extreme" ???
  2001-05-06 13:40:08  jim_warlock [Reply | View]
  
  
  Excellent article, etc. you know :)
  To get to the point... I've been involved in software
  projects (throughout my years in university) for some time now
  and I've always been taught that the best way to deal
  with projects is using the approach you write about...
  The Uni. is the client in this case and you start up with
  a vague idea of what your product is going to be... so you make
  up a start-up plan (a sort of mock-up design) and then as you
  go along you refine it, add features to it and even
  redirect the original plans to other areas...
  
  but i'm still not making my point am I? :) well I don't quite see
  how this classifies as eXtreme programming...could you
  please clarify?
  
  --
  Dimitrios "Jinx" Psychogios
  MSc. Data Comms. & Networks
  University of Hertfordshire
  
  D.Psychogios@herts.ac.uk
• Why "Extreme" ???
  2001-05-07 11:09:57  chromatic [Reply | View]
  
  
  As I understand it, Kent Beck chose the word "Extreme" to convey the idea of turning all of the knobs to 11. Instead of using a design-code-test-debug-build-ship approach that takes each step in order, XP says to design continually, test continually, build continually, review continually, ship early and often.
  
  It's extreme because it advocates doing all of the good activities of software engineering as much and as often as possible.
  
  (On the other hand, if you mean the article simplifies things, you're absolutely right. The real world's too complex to cover everything in 500 words. There are still plenty of things to learn from XP, even if you find it's not appropriate in your situation. :)