Fog Creek Software
Discussion Board

Extreme Programming

Hi !

I just started to read about Extreme Programming. It seems to be very efficient developement process, going against many preconceived ways of doing things. It looks so much different of the traditionnal way of working that I'm wondering if many companies are using it. Beside that, I'm wondering if developpers working with such a method are happy with it.
Sure, it looks like a modern, efficient and powerful method, but some aspect of it make me feel awkward with it. I wonder, for instance, if I would really tolerate that anybody of the team could just do anything with the code I wrote. I'm also kind of 'lonely programmer', always wanting to be left alone doing what I have to do, and the idea of always working in pair disturbs me !

Anyone already had experiences with Extreme Programming ? Would you fit in a team using it ?

Tuesday, October 22, 2002

The team I work in use extreme programming methodology quite a lot, and it works well for us. The "anyone can change anything" philosophy works OK up to a point. We use source control (clearcase) to help us here. Different parts of the project (directories) are the reponsibility of different people, and each section has one person responsible for doing the merges into the main working branch for that directory. It keeps a bit of sanity going.

As for pair programming. Just think of all the times when you are not sure of something, and have someone sitting shotgun with you helping you to get something tricky done the first time. In general we find that the pair programming really helps the first time you do anything, and then once you are happy that you know what you are doing, then working alone may be more efficientr.

I'd also recommend "The Pragmatic Programmer" by Dave Thomas and Andy Hunt to you. Being an extreme programmer is good, but being a pragmatic programmer may get you further  :-)

best regards,

stephen hill
Tuesday, October 22, 2002

I would second the recommendation of "Pragmatic Programmer".  It is a great book. 

The thing I like best about XP is its focus on unit tests.  I now write unit tests first and then write the code.  It took a couple of days to get used to, but now I don't know how I developed before.

Tuesday, October 22, 2002

Although I have no experience with XP, I recently looked at it myself. What I found out, is that there's pros and cons for every method, so make sure you read the cons as well (and not just the sweet stuff). This seems like a good starting point for that:

You also have to evaluate what kind of systems you're working on, e.g., in-house applications are very different from embedded systems (and the latter may not suit the XP style that much).

Tuesday, October 22, 2002

I like XP, and have managed to do most of the practices of XP at one time or another at work.

Test First Programming seems, in my book, to be the hardest to implement, especially for GUIs.  Test First for the document/view (or Model/View/Controller) can get hard, and I haven't put enough time into it to figure out how to do it "right." 

In other words, I love XP on paper, but the human politics of introducing and planning for change are HARD.  ("What do you mean, you don't know when it'll be done?" is a common refrain ...)


Matt H.
Tuesday, October 22, 2002

i've read things about how unit tests are good, etc., but where does one go to learn what *exactly* a unit test is, and how do i start making them and implementing them with the code i'm writing?

i'm looking for something similar to joel's article "Getting things done when you're only a grunt", , but i'm looking for something a bit more detailed.

i've read Code Complete, and flipped through Pragmatic Programmer... will Prag. Prog. do it for me?


Tuesday, October 22, 2002

Unit testing:

Tuesday, October 22, 2002

Unit tests are just code which tests other code.  These tests signal pass or fail.  For example, if you were testing a factorial function, you'd test that 10! = 3628800 and 11! = 39916800, and possibly cornercases like 0!,-1! or numeric overflow if your spec defines them.

You'll want a testing framework that allows you to run these tests in convenient ways, such as at the end of a build so it can signal build failure.  The jUnit framework is for Java, which can integrate with Ant builds.

Part of the benefit is writing your code so it can be easily tested.  Another is it gives you confidence in changing another person's code (which is why code ownership is missing from XP).

Tuesday, October 22, 2002

i guess i'm looking at this as a programmer that is tasked with maintaining large production programs that constantly need to be updated and reworked as the customer's needs change.  (and yes, it's ok that the customer asks for changes every month.  but i would like to minimize my involvement...)

it's easy to say that you'd test a factorial function by ensuring the calculation is correct.  it's much more hairy to figure out how to unit test what's essentially a procedural program, without running the entire thing.

basically, i guess i'm trying to figure out how to take a large, procedural, production program and refactor it to be more modular, because we have a ton of programs that are mostly copies of each other.  we'd really benefit from code reuse.

Tuesday, October 22, 2002

It sounds to me like you might try looking at Refactoring by Fowler. 

There is a refactoring mailing list on Yahoo groups.  There has been a lot of talk recently about making changes to existing systems that lack unit tests.  There were basically 2 schools of thought:

1.  Write unit tests for exisiting code even thought this may be very painful/time consuming.  Then start refactoring.
2. Do some "simple" or "easy" refactorings first to make writing test easier, then start adding functionality writing tests as you go.

I personally can't speak from experience about 1 or 2 because I have been fortunate enough to have tests already in place.

Tuesday, October 22, 2002

Here are two other places you might want to check out:

Grady Booch occasionally posts here

This site sometimes has some good pro/con debates on it

Imo, the biggest impediment to using Extreme Programming is getting your employer/client to support it.  For example, the XP methodology requires a business analyst or in XP terms "a customer" present.  Whom do you think your client is going to supply your project team with?  A very busy domain expert or some end-user who was hired only two weeks ago?

Btw, Kent Beck has been booed off stage at least once in the past.  I guess the PMs in the audience simply were not willing to listen to what he had to say. 

Charles Kiley
Tuesday, October 22, 2002

IMHO, Extreme Programming is a set of practices that are best approached incrementally.

By that I mean:  Look at the various XP practices, and try to implement them as best you can.  You'll probably be able to implement some fully, some only partially, and some not at all.

See what works, and what doesn't.  In fact, XP has a rule called Change The Rules, which means that you should add, change, or remove rules as appropriate for your own situation.  XP practices don't fit every project in every corner of the globe until the end of time.

On the other hand, each XP practice is a well-reasoned recommendation based on a lot of experience and thought, so it's worth trying them if you can.

Brent P. Newhall
Thursday, October 24, 2002

A lot of people look at XP, and only see the easy bits. "Oh, you don't do up-front design. Anyone can change anything. That must be so easy."

Don't believe a word of it. XP is _hard_. It's worth it. It's worth every drop of blood you sweat, but never for a moment believe that it's an easy option.

The practices require a lot of discipline. Pair-programming requires tolerance and the ability to adjust your way of operating to suit your pair. Pair-programming also robs you of the time you spend each day reading Joel on Software. Try doing that when someone's looking over your shoulder. Test-first programming requires strong discipline to make sure you write the tests, and good design skills to ensure your code is testable in isolation. Refactoring requires the strength to stand up to a looming deadline, and say "I need to get this right."

And once you get past that, there's a layer of management who believe, who strongly and powerfully believe in firm estimates and fixed-price contracts, the two things that XP can not deliver. People who have been burned time after time by enormous cost overruns and deadline extensions, but who still like the certainty of having a little chart that, at the beginning of the project, says that it will end on such-and-such a date, costing however-much dollars.

And even the technical management will balk, having trained for their entire professional careers to design, then code, then test, then deploy, despite the fact that the designs always get changed, the tests always uncover, too late, some critical flaw, and the deployment is a nightmare. If you try to introduce XP, even if you know it's a step in the right direction, these people will be looking over your shoulder for the first fault, and dragging you back to a system that may not work, but at least they're familiar with.

XP is fucking wonderful. I've been on some projects where it was embraced fully, and they've been the projects with the most consistently met deadlines, the best customer satisfaction, and the code I've been the most proud of having written (or pair-written).  But in a hostile environment, or with programmers who think it's going to be an easy ride and aren't prepared for the effort, beware.

Feeling anonymous
Friday, October 25, 2002

I liked "Seven Slides and a Fight:
How Extreme Programming improved our user-centered design process, but not our social skills"

The video of this talk is online.

Just me (Sir to you)
Wednesday, October 30, 2002

*  Recent Topics

*  Fog Creek Home