aspose file tools*
The moose likes Agile and Other Processes and the fly likes Pair Programming Case study Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Pair Programming Case study" Watch "Pair Programming Case study" New topic
Author

Pair Programming Case study

Simon Xu
Ranch Hand

Joined: Aug 16, 2000
Posts: 235
Hi,
Does anyone know where I can find the programming example using pair programming, like Martine's bowling? I would like to learn more. Many thanks.
Simon
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Don't know if this helps at all but have you searched www.pairprogramming.com?


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Simon Xu
Ranch Hand

Joined: Aug 16, 2000
Posts: 235
Lasee,
Thanks for the link. I did not find any complete example as bowling score. Can anybody help? thanks.
Simon
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Mhh, I don't know of any other example, sorry.
What would you like to learn from it?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Simon Xu
Ranch Hand

Joined: Aug 16, 2000
Posts: 235
I know people use it to do case study for different purposes. I did it for knowledge based, and I would like to have more cases. Thanks.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Sorry, I guess I don't fully understand...
The best way I know to learn about Pair Programming is actually practicing it. What do you think about just trying it for yourself?
Simon Xu
Ranch Hand

Joined: Aug 16, 2000
Posts: 235
Ilja,
Thanks for your reply. My purpose is not to learn how to do pair programming, but to do case study about how knowledge grows during pair programming.
It is hard to find a very good example like bowling (well documented). Even we can try, but we need to write all the communication between pairs.
Thanks.
Simon
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Simon,
Sounds interesting. What is the scope of your case-study ? A mini project , perhaps?
Do your pairs stay the same in the case study ? Do you take into account human behaviour? Friends may not necessarily pair program better -they may value their friendship over project interests ( depends on what brought them together as friends first ).
P.S. I've never come across the bowling example, but I've known a case of a friendship built over several years within the context of team-building destroyed in one night-out bowling. They never talked together again, let alone pair-programmed. An extreme example but there is always distractions from the outside world to consider.

I guess it is the organisational knowledge that counts - learn and retain to pass on to the next pair programming excercise. So the mentor mentors the other programmer in the first excercise , who then becomes the mentor in the next pp excercise centred around the same piece of work (Hopefully he/she has made study notes to bring themselves up to speed in the interim.) In fact I think the notes etc to help retain the knowledge should be the outcome from each pp excercise. A team walkthrough to learn/accept the notes into the organisational team and stored on-line in a standard format would keep it within the organisation and be available to all.
My two pennies-worth.

regards
[ May 26, 2003: Message edited by: HS Thomas ]
Simon Xu
Ranch Hand

Joined: Aug 16, 2000
Posts: 235
HS,
Thanks for your input.
I find the pair programming is a very interesting development process where the knowledge is intensive and documented well. My purpose is to collect more examples like bowling (http://www.cs.vu.nl/~frankh/abstracts/VSW02.html), to see the patterns in pair programming. During the process, the knowledge (domain, programming) of two programmers are growing. There are some processes: like assimilation and accommodation. Some facts are added into existing knowledge, some are rejected. There are many interesting things in these processes.
Regards,
Simon
Simon Xu
Ranch Hand

Joined: Aug 16, 2000
Posts: 235
Sorry, the correct link for the bowling example is
http://www.objectmentor.com/resources/articles/xpepisode.htm

Simon
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Hi Simon,
The bowling example is pretty NEAT.
Starting off, I thought the discussion covered Interview techniques , requirements gathering ( or digging) and then fringed into modelling before starting to discuss the test and code.
But I suppose it had to (as it's a tiny problem and only an example).
In practise , pair programming roles will involve only Testing and Coding to a given set of XP requirements.
What do you think ?
regards
[ May 27, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
In practise , pair programming roles will involve only Testing and Coding to a given set of XP requirements.
What do you think ?

I find the example to be *very* representative for typical pair programming.
How *can* you discuss testing and coding *without* also discussing requirements and design???
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Hi Ilja,
How *can* you discuss testing and coding *without* also discussing requirements and design???

I'd assumed high-level requirements and design were pretty much fixed by the time pair programming occurs, more so if the scope of the project is large. ( 90 % of the time anyway)
By all means pair programmers would discuss low-level requirements and design. Probably should have made that distinction clear.
The pair programmers may have been involved in the high-level design (abstract) but then again , more likely not .
I'm not sure how the above fits in with XP thinking.
regards
[ May 27, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
I'd assumed high-level requirements and design were pretty much fixed by the time pair programming occurs, more so if the scope of the project is large. ( 90 % of the time anyway)
By all means pair programmers would discuss low-level requirements and design. Probably should have made that distinction clear.

OK.

The pair programmers may have been involved in the high-level design (abstract) but then again , more likely not .
I'm not sure how the above fits in with XP thinking.

In an XP team, they would have been involved.
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
In an XP team, they would have been involved.

Even with an elapsed time frame of months between the pair programming and the high-level design ? OK in XP , they'd code to the minimum requirements. If certain features of the high-level design had been held back till months later , and now you've got new pair programmers ?
OK , I'll agree that revisiting the high-level design would count as being involved.
Agreed, Ilja.

regards
[ May 27, 2003: Message edited by: HS Thomas ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Simon
You may find this link useful.
PairProgrammingPattern
regards
Simon Xu
Ranch Hand

Joined: Aug 16, 2000
Posts: 235
Thanks for the discussion.
During pair programming, many kinds of knowledge are involved, such as domain knowledge, patterns and principles, programming techniques, (those are language independent), programming knowledge so on. Another one is design decisions which could be divided into high and low levels. Any others? Do you see any good way to represent them? of course, some tacit knowledge can not be easily transfered to explicit knowledge.
Thanks.
Simon
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Hi,
How does Code Ownership come into play
while Pair Programming ?
regards
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by HS Thomas:
How does Code Ownership come into play
while Pair Programming ?

It doesn't. Well, it shouldn't if you're complying with XP practices of which one is "Collective Code Ownership".
Doing PP doesn't mean neither that the driver or the other guy would "own" the code they produce. Not even that the two would own the code together (unless the two are the XP team).
Right?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
In Pair Programming, both partners should be equal - which is near to impossible if one of them owns the code. So both need to own it.
Now, if you are changing partners often (which in PP is a good thing), you end up doing Collective Codeownership rather automatically...
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks.
So in an XP team 2 OO developers are assigned to a unit test first and then code piece of work. I was going to ask just how far architectures need to be settled first, then thought that Pair Programming just applies to Java code, so the question is irrelevant. Right ?
If parts of the system generated objects from XML or parts of the architecture need reviewing,
do they come under PP ? Where and how does the XP process draw the line ? Or is it left up to the PPmers where they want to draw the line (in line with their increasing knowledge) ?
Seems to me a third party review with the requisite skills is required.( At least until all PPmers in the team fully understand the system).
regards
[ May 29, 2003: Message edited by: HS Thomas ]
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Ok. As a newbie in XP, let me try to answer this question wrt XP practices. And guys, correct me, please.
When a PP pair sits down they already have been given a story (?) to implement. So they don't need to think about architecture, unless they figure out a problem which requires changes affecting the system metaphor (?).
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:
When a PP pair sits down they already have been given a story (?) to implement. So they don't need to think about architecture, unless they figure out a problem which requires changes affecting the system metaphor (?).

Yes and no...
You are right, when a pair sits down, there already have been discussions about how the story fits into the architecture (in the planning meetings, for example).
OTOH, with the merciless refactoring going on, they never stop thinking about it - they always have an eye on how the code develops and wether it still fits into the big view. That's one of the things typically much easier to do for the one currently not sitting at the keyboard, by the way...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
So in an XP team 2 OO developers are assigned to a unit test first and then code piece of work.

Just as an aside, in XP tasks aren't assigned, but choosen by the developers (from those scheduled for the current iteration, of course...).

If parts of the system generated objects from XML or parts of the architecture need reviewing, do they come under PP ? Where and how does the XP process draw the line ? Or is it left up to the PPmers where they want to draw the line (in line with their increasing knowledge) ?

Yes, XP doesn't draw a line here, but trusts the developers to figure it out.
They might decide to
- just continue coding,
- address the issue in the daily Stand Up Meeting,
- do a short design discussion on the white board,
- switch partner with a more experienced developer,
- ask a quick question into the room,
- gather the team for a bigger discussion,
- lots of more possible things (I once participated in a quadruple programming session for an hour)
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks Ilja and Lasse.
XP sounds promising.
The strengths seem to be in the short cycles of meet,plan,test,design,code Collectively.
If ,as is said, " To err is human", and a blame culture shouldn't exist in an XP team, does the whole team get fired or can these human traits be weeded out( or even humans weeded out), given that the development cycles are short.
How long does it take , on average , to build an XP team ?

I know XP teams have to be small to work effectively but as the knowledge required now crosses into several technologies , your team can expand quite dramatically. Be it , half of them may be there in a consultative role.
Does XP not take into account people's different learning curves ? Someone may not learn so quickly but be a team-player in other ways.
My thinking is that XP is most suitable for short-lived teams (for example in consultancies).
Longer-lived, maintenance teams with periods of apparent inactivity need a different structure ( for example Sit Down Meetings)

regards
[ June 01, 2003: Message edited by: HS Thomas ]
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
To some degree, I'd say "HS" is correct about XP not being as suitable for maintenance orgs. For instance, I am currently in a maintenance project where the tasks are (ideally) shorter and smaller than in development projects. For example, last week I did one 14+ hour workday with a couple of colleagues wondering what the heck made our system put out SMS response messages that were never triggered by a pull message. Not a single line of coding, a lot of head-banging, a good amount of frustration, and finally, a patch from BEA, which prevented WebLogic from reprocessing the JMS persistence file again upon server restart... I wouldn't call that too XP-friendly an environment.
However, we've also implemented several slightly bigger change requests where XP fits like a glove. Point being that you should use XP where it feels right and even maintenance projects may fit the profile.
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
use XP where it feels right and even maintenance projects may fit the profile.

I couldn't agree more. For certain, a lot can be borrowed from XP, like Pair Programming.( Old maintenance programmers may find themselves thinking " Hey, we've been doing that for years!".)
And even, "Test first , then design" has been around in some form.
XP tools e.g. Pair Programming, the JUnit framework HOPEFULLY makes software development more programmer friendly and adaptive to change - agile is the keyword.
regards
[ June 02, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
The strengths seem to be in the short cycles of meet,plan,test,design,code Collectively.

Yes. Most importantly they provide much data you can use to actually *manage* the project (besides just "motivating" developers, crossing fingers and skipping the final testing phase... ).
If, as is said, "To err is human", and a blame culture shouldn't exist in an XP team, does the whole team get fired or can these human traits be weeded out( or even humans weeded out), given that the development cycles are short.

I think I don't understand the question. Can you please elaborate on your doubts?
How long does it take, on average, to build an XP team?

Most teams seem to report that they do miserable in the first couple of weeks, OK in the next ones and first benefits are seen after a month or so. Of course this heavily depends on the availability of an experienced XP coach and where the team is coming from. If there is a team worthy of the title "team" at all...
I know XP teams have to be small to work effectively but as the knowledge required now crosses into several technologies, your team can expand quite dramatically. Be it, half of them may be there in a consultative role.

There are two effects in an XP team, here.
First, the team strives to hold the system simple - no technology is introduced just because its hip; there need to be a compelling business need.
Second, because of the close collaboration in the team, knowledge spreads rather wide.
Does XP not take into account people's different learning curves ? Someone may not learn so quickly but be a team-player in other ways.

Yes. Why do you think XP doesn't address this?
My thinking is that XP is most suitable for short-lived teams (for example in consultancies).

The C3 team (which "invented" XP) used it for the full four years of the project, if I remember correctly.

Longer-lived, maintenance teams with periods of apparent inactivity need a different structure ( for example Sit Down Meetings)

There is the saying that XP projects are in maintenance after the first week.
I guess I neither fully understand why you think that longer lived teams need to have periods of "apparent inactivity", nor why Sit Down Meetings would be "anti-XP".
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
quote:
--------------------------------------------------------------------------------
If, as is said, "To err is human", and a blame culture shouldn't exist in an XP team, does the whole team get fired or can these human traits be weeded out( or even humans weeded out), given that the development cycles are short.
--------------------------------------------------------------------------------
I think I don't understand the question. Can you please elaborate on your doubts?

I think I was Confusing Collective Code Ownership with Collective Overall Responsibility. Now my understanding is that XP teams have team structures like you'd find in an RUP team i.e. Project Manager, Team Leaders, Testers, XP Programmers.
(I was also trying to reveal my ignorance with wit, not very successfully , hence the confusion).
Previously ,I had assumed that XP Pgmers had a
lot more responsibility than just coding and testing.
regards
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
I guess I neither fully understand why you think that longer lived teams need to have periods of "apparent inactivity", nor why Sit Down Meetings would be "anti-XP".

"Long-lived teams" assumes a period of growth,hence larger teams and more maintenance.
By maintenance I usually mean looking at code that has passed through several hands over the years.
Sit Down Meetings to discuss the code would be one way to find able and willing volunteers to take it over.

Sustaining the agileness of the programmers over time may be a problem , do you think? Unless XP has been drummed in right from the start.....
[ June 03, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
"Long-lived teams" assumes a period of growth,hence larger teams

Mhh, I can perfectly well imagine a long-lived team of constant size. Why would the team itself grow significantly?
and more maintenance.
By maintenance I usually mean looking at code that has passed through several hands over the years.

Remember that in XP you are constantly looking at code that has passed through several hands over the days and weeks? I don't know why years would make a difference - as long as the team doesn't stop to strive for perfectly clean code, conforming to both the teams Coding Standards and the System Methaphor.
Sit Down Meetings to discuss the code would be one way to find able and willing volunteers to take it over.

What does "take it over" mean in the context of Collective Code Ownership?

Sustaining the agileness of the programmers over time may be a problem , do you think? Unless XP has been drummed in right from the start.....

I don't think that it would be a problem, unless they are working in a hostile environment. What makes you think that it would be?
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Mhh, I can perfectly well imagine a long-lived team of constant size. Why would the team itself grow significantly?

more functionality, more Lines of Code. There is a limit to the number of LOC any programmer
can look at in a day. The solution is usually more resources or larger implementation times..(or splitting the Pair Programmers to work individually -last resort)
What does "take it over" mean in the context of Collective Code Ownership?

In order to own anything, one has to accept it first.It's the norm, a passing phase (e.g. User Acceptance Testing). Adhering to standards like putting a date and initials against changed lines of codes was a form of acceptance. IDEs do that automatically now.
IMHO, As you can tell I've never knowingly worked in an XP environment.
Do XP teams in OO projects work the same way everywhere ?
Guess it's time for some reading up on XP.
Illja, thanks for the link on the other thread.
That, along with Alistair Cockburn's book seems just the ticket for the journey.
regards
[ June 03, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
Why would the team itself grow significantly?
--------------------------------------------------------------------------------
more functionality, more Lines of Code.

Probably, though not necessarily a linear correlation.
There is a limit to the number of LOC any programmer can look at in a day.

Yes - but only because there is more code doesn't necessarily mean that he has to touch more code to get the same amount of functionality implemented. If the existing code has a high chosion and low coupling, it might well be less, as you can make use of the existing infrastructure.
The solution is usually more resources or larger implementation times..

There are in fact XP teams reporting exactly the opposite effect!

(or splitting the Pair Programmers to work individually -last resort)

Why would you do that? Seems to me that it could only reduce their effectiveness...

In order to own anything, one has to accept it first.

Yes - when joining an XP team, a developer had to accept that he owns all the code, together with the rest of the team.
Do XP teams work the same way everywhere ?

Certainly not!
It's just that I currently can't connect some of your statements to anything that I could imagine looking like XP...
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Yes - when joining an XP team, a developer had to accept that he owns all the code, together with the rest of the team.

What ! warts and all! No reflection on the XP team, but there are always newer,better ways of doing things.I guess you'd reply that an XP programmer would feel compelled to make any code better subject to business needs/requirements.
That sounds good. Since most programmers I know are not conversant with business needs, nothing short of a good prod will induce a similar compulsion.
It's just that I currently can't connect some of your statements to anything that I could imagine looking like XP...

I am not surprised . I am only relating my current experiences to what has been said about XP. Some experiences have been XP-like IMHO but with some of the pro-activeness (agileness) missing.It'll be good to try and track some new XPeriences (pardon the pun) at work.
Doubt I'd be lucky enough to work on an XP team. Full-blown XP will be too much of a radical change on the kind of projects I'm used to.
Thanks, Illja. Hope I can pick your brains at a later stage when I've read some literature on XP first. I think it has many strengths. Weaknesses, who knows yet!
(As an aside and I have to emphasise that XP and RAD are different approaches.
Why isn't RAD so hot anymore ? - Could it have been that using all those templates sucked the creativity out of the tasks. RAD was introduced wrongly in some projects, created a creativity vacuum instead of introducing new horizons creatively by giving developers something else to be creative about first(learning and practising OO) and then replacing mundane tasks with templates, code generators while still keeping the core knowledge intact i.e. knowledge that can figure out the generators aren't used wrongly and producing rubbish? BUT second time round the block, and they're up and running , but this time armed with new core knowledge about OO,using slightly different generators which just slip into place. Only they're not calling it RAD anymore. It's usually the core knowledge that survives and grows.)
Need to find what is core to XP and that's very difficult without actually practising it.Since XP puts emphasis on the agileness of the developers I expect a much better success story.
IMO agileness (leaping into action to solve defined problems with known solutions) and creativity (seeing a need and finding a solution) can be treated on par.

regards and thanks for listening . Apologies if what I've said doesn't make much sense to you.And I wasn't criticising XP but just trying to understand.
I MUST add Illja,that your input has been very valuable to me in shaping my thinking about XP.
[ June 04, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
What ! warts and all! No reflection on the XP team, but there are always newer, better ways of doing things. I guess you'd reply that an XP programmer would feel compelled to make any code better subject to business needs/requirements.

Yes, that's exactly what I'd reply!
That sounds good. Since most programmers I know are not conversant with business needs, nothing short of a good prod will induce a similar compulsion.

I am not sure wether I am able to follow your wording here...
Nevertheless I want to point out that in an XP team the developers are in constant, direct contact with the Customer (especially during the regular planning meetings) and (and at least a big part of) the business needs are written down in automated tests as specified by the Customer. The developers ability to work to those business needs is also measured every couple of days. Therefore it would probably be hard for them to be ignorant of them...

Doubt I'd be lucky enough to work on an XP team. Full-blown XP will be too much of a radical change on the kind of projects I'm used to.

Well, many of the practices can also be done by yourself in isolation. You could even do your own small planning game. It probably won't be as effective, but at least you get some practice, can provide more data to your manager and possibly even "infect" your environment to some amount...
Thanks, Illja. Hope I can pick your brains at a later stage when I've read some literature on XP first.

Certainly!
What literature are you planning to read?
Why isn't RAD so hot anymore?

I don't know much about RAD, but I'd guess that it didn't take long term maintainability into account.
Need to find what is core to XP and that's very difficult without actually practising it.

Yes. In fact I learned the most about XP by applying (part of) it to a hobby project.

and thanks for listening.

You're welcome!
Apologies if what I've said doesn't make much sense to you.And I wasn't criticising XP but just trying to understand.

Yes, I guessed that.
And I didn't have any problems with anything you wrote - I just learned to be very carefull in regards to potential misunderstandings...
I MUST add Illja,that your input has been very valuable to me in shaping my thinking about XP.


It's fun discussing with you!
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks Illja.
I was re-reading the posts when I came across a question I'd missed.
What literature are you planning to read?

So far I've got the following:

  • RUP vs XP
  • Agile Software Development
  • ASD - Principles, Patterns, Practices

  • I'm looking for some references where the AOP and XP approaches are treated together. I'm surprised by some comments that AOP is an antidote to XP.This thinking seems fundamentally flawed as I feel not every problem can be AOPed nor every problem is best XPed.
    The modularity approach of AOP sounds an attractive option in some cases.
    Any recommendations ?
    regards
    [ June 09, 2003: Message edited by: HS Thomas ]
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    Hmmm, I musta posted that Agile Software Development link, because it's back to a server inside my work. Sorry about that. PUt that title in Amazon or any good bookstore and you'll get TWO (or more) books - Alistair Cockburn and Robert Martin. Cockburn is a good survey of many agile methods, Martin is good on some specific techniques and OO goodness.


    A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Thanks Stan.
    I could have sworn that link worked earlier.
    I've changed it to point to Amazon.
    regards
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by HS Thomas:
    I'm looking for some references where the AOP and XP approaches are treated together.

    Using google, I only found one paper - and that one seemed to be of a rather academic, hypothetical nature. I think AOP (we are talking about Aspect Oriented Programming, aren't we?) is simply to young - it isn't very well understood yet in general, let alone interactions with methodologies etc.

    I'm surprised by some comments that AOP is an antidote to XP.

    I would be surprised, too. Where did you get those from???
    This thinking seems fundamentally flawed as I feel not every problem can be AOPed nor every problem is best XPed.
    The modularity approach of AOP sounds an attractive option in some cases.

    I think they are mostly orthogonal. XP doesn't prescribe things like programming paradigms. You can do XP with Prolog, if you like.
    There are, of course, some minor implications. How do you test-first-develop aspects? How do you refactor them? Are there refactoring steps / code smells driving you from OO code to AO code? How do you manage code dependencies in the presence of aspects and Collective Codeownership? All those questions probably still need to be explored.
    On the other hand, aspects give you just another tool in your bag to remove code duplication (even where OOP fails to do so). As the removal of duplication is one of the main goals of XPers, I find it silly to say that AOP is anti-XP per se... :roll:

    Any recommendations ?

    On XP in general:
    http://www.extremeprogramming.org/ gives a nice introduction (though it is somewhat outdated at some minor aspects - pun not intended ).
    http://www.xprogramming.com/xpmag/index.htm has some more recent articles on selected topics - very recommendable!
    And then there is http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap - if you aren't afraid to get lost...
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Thanks for the extra links, Illja.
    I'll watch these sites for developments on AOP especially the Wiki ones.( yes, I meant Aspect Orientated Programming not the other , Attribute Orientated Programming )

    I would be surprised, too. Where did you get those from ???

    From discussion groups so nothing substantiated.
    Other than from experience , perhaps. The tone of the comments was quite bitter .
    I think it was mainly on the Server-side forums.
    regards
    [ June 13, 2003: Message edited by: HS Thomas ]
     
    Consider Paul's rocket mass heater.
     
    subject: Pair Programming Case study