RE: eXtreme Programming

["Bradley Ward" <brad@wardsrus.net>]

I'll add 2 pennies worth if I may. I'm basically brand new to XP as a methodology, but I have over 20 years experience in almost every aspect of XP as a powerful method for doing software development. I ran my own company (day-to-day job = chief architect/developer) from 1980 to 2000, When I first started reading Kent Beck's "Extreme Programming Explained" a few weeks back, I immediately recognized why we had such a strong team of engineers; it was because of the agile techniques we used (the "strong team of engineers" statement comes both from repeated comments from customers, but also from many of those engineers who now hold senior positions in other development organizations around town (those of you on this mailing list know who you are <G>)).

So I'd like to comment on two aspects of Corey's original statements based on 20+ years of experience with these techniques.

 

First, to Corey's point about experience. Whether Corey intended it or not, what I heard from his statement was that you need an experienced team to successfully do XP. No argument about the need for experienced developers on the team, but I would say that it is not necessary that everyone be experienced. We successfully used junior people all the time. In fact, there are probably more than one engineers on this list that did mainstream project and product development for my company while working for me as a coop student. So experience was not a necessity, but being bright was Those that did not score as high on that last point tended to move on to more structured environments.

 

My interpretation of my XP readings as applied to this experience issue is that pair programming would be where inexperienced programmers very rapidly get experience. Although we followed most of the XP tenets very closely, we never did the pair programming thing. What we did do is let very junior people (including co-ops) take on tasks and run with them. Through a combination of great teamwork and a very open, walk the halls and talk to any body of any level, write stuff on the whiteboard then erase it mode of operation, those very junior people learned very quickly, and produced some fine work. On many occasions co-op students went out by themselves to corporate clients to perform installations and other tasks and never once did we have a customer complaint about their lack of ability. And these were 24x7 manufacturing applications, not desktop apps where the reboot and call me in the morning solution works. So while I will admit I'm still a bit skeptical about this pair programming thing, I am a big believer in the casual interaction of a close knit team that XP promotes.

 

My second comment about Corey's original email is in the area of refactoring. I do not consider solid refactoring to be rework at all. In fact, in almost all cases where I refactor (and I do that almost continuously), I do so because I can avoid future work. I have always had an inborn aversion to the re-use of code via the copy and paste mechanism as I have seen in almost every consulting/contracting job I have done. I sometimes think I am as unable to violate the OOO rule (once and only once) as I am unable to violate the law against murder. You might find me copying or even doing new coding  that is substantially similar to old code a second time, but when I see the same pattern the 3rd time, the refactoring bell goes ding and away I go!

 

I would therefore contend that if something does in fact feel like "rework", then this may be a warning sign that there is something amiss in the design, or the overall vision of the project is not well understood (a bad "metaphor" in XP parlance). So even if it is rework, it is something worth doing sooner (while only 10,000 other lines of code depend on it) rather than wait until later (when 100,000 lines of code depend on it).

 

Sorry for the length of this reply. That is probably 3 or 4 cents worth rather than 2 cents worth.

 

Brad

 

 

 -----Original Message-----
From: Angus Berry [mailto:angus.berry@elken.com]
Sent: Sunday, November 09, 2003 10:35 AM
To: Corey; Jason Chambers; 'Atlanta Java Users Group'
Subject: RE: eXtreme Programming

Corey,

 

I'm interested in Jason's thread and wonder if I might draw out your experience a little more.

 

Trying to sum up one aspect of what you're saying:

You'd use XP with an experienced team, using their skills on a new business requirement.

 

However, would you use XP with the same team using (and thereby acquiring) new skills on a new business requirement? For example an XP Swing team doing JWS or an XP Struts team doing J2ME.

 

I'm sure there's quite a gray area here, in how far the skill set stretch is, but I appreciate any insight that enables me to look before it comes time to leap... hindsight is 20/20 :-)

 

Angus

-----Original Message-----
From: Corey [mailto:corey@spectrumsoftware.net]
Sent: Saturday, November 08, 2003 7:42 PM
To: Jason Chambers; 'Atlanta Java Users Group'
Subject: Re: eXtreme Programming

 

    Jason,

 

    Personally I think that TDD (test driven development) as one aspect of XP

    is a very good thing and have used it successfully myself. On other aspects

    of XP or Agile methodologies, I believe that the level of maturity of the team

    makes all the difference in the world. I know for a fact that you can't take a

    bunch of inexperienced programmers and have them implement a project

    successfully with XP. Knowing what will work and what will require further

    attention requires experience, there is no substitute for it and no amount of

    "refactoring" is going to change that fact. Rework in any form, regardless

    of what you call it, is still rework. An experienced team can visualize the

    framework for a project and can set about breaking it apart for incremental

    development. An inexperienced team cannot visualize the whole to begin

    with and will spend a great deal more time refactoring work that they have

    already done in order to make everything work together in the end. Of course

    these are my personal thoughts and experiences on the subject. I'm sure there

    are plenty of XP zealots in this crowd that would gladly take a flame thrower

    to everything that I have just said :-/

 

    But with that said, is Agile development a bad thing? Of course not! We have

    a very strong team where I am currently at and Agile methodoligies work very

    well. In the dot.com days I worked at a startup with a mix of completely inexperienced

    programmers and some very experienced programmers. The desire to implement

    XP was there, but the ability to execute was not. We spent a great deal of time

    analyzing the requirements (which were changing constantly) and putting together

    our base framework. Once we had completed our analysis and design of the

    basic framework, we were able to split the work up in a more XP like fashion and

    were able to easily accept the changes to the requirements as the customer changed

    their mind.

 

    --Corey

______________________________________________________
William C. Brown
Chief Architect. Spectrum Software Inc.

 

11445 Johns Creek Pkwy
Duluth, GA. 30097.
Suite 300.
Tel > 770.813.4952
e   > corey@spectrumsoftware.net
web > www.spectrumscm.com
yahoo > caldron68

----- Original Message -----

From: Jason Chambers

To: 'Atlanta Java Users Group'

Sent: Saturday, November 08, 2003 3:22 PM

Subject: eXtreme Programming

XP’ers

 

I am very interested to hear about your experiences with XP. Do you follow XP to the letter of the law? What bits did you leave out? What bits did you add? What team sizes? What kind of projects? What was the fallout after you implemented XP? How many just wouldn’t accept the change? Did you have any issues maintaining the XP discipline? What was the general feeling from the team? Which aspect of XP had the most controversy with your team?

 

I have been reading about aspects of agile methodologies for a while now and am a big proponent of the philosophy on the whole. However, I have yet to convert theory to practice. I was lucky enough to see an XP lab this past week in operation and was mostly taken aback by the level of energy in the lab and the camaraderie amongst the team.

 

Please share your experiences – good, bad or ugly.

 

Jason