Fog Creek Software
Discussion Board

My problem with Xp programming

This could apply to any rapid lifecycle/ refactor often type of process:
Couple months back, I got picked to do a small internal app for our Client Services department.  I did some basic architecture, slightly more then what needed, but I knew customer satisfaction was key on this project, so I was hoping to try an XP like process on it.  Over the months, between working on and off on it, its developed from a small app to a full fledged application with a ton of features, a complicated database, and some very clean orginal code with a lot of bandaides all over to keep up with the requests.
    Now, with XP programming, i'm supposed to only program to what i'm given, not "over design", and just get results.  The problem is, now that i've gotten into the pattern of delivering quick results in a "fix it quick" type fashion, i'm stuck.  This code needs some serious refactoring, but I feel we're way beyond that.  Is there a point where you say "oh, that last little request is too much, give me a week to re-architect the whole thing?".  I'm definatly new to owning a project, and I only have a couple other people helping me with it on and off. Any suggestions would be appreciated.

Vincent Marquez
Tuesday, March 25, 2003

We use many of the principles of XP, but we are not purists.

When we start a new project, we do our user stories to see how the product should work.  However, we do spend a great deal of time doing design.  BUT, we don't spend a lot of time dreaming up features that aren't in the user story.

The user stories and design are given priorities and time estimates, and we gauge our progress accordingly.

If someone comes in with a change to the user story (which often occurs), we give them a frank evaluation of how far back it will set us.  Then they (usually management) can decide if the time to refactor is worth it.

Tuesday, March 25, 2003

Refactoring is something you need to do constantly throughout the process, not wait until you're behind the 8-ball. Even so, you'll probably find that refactoring will be faster than the alternative of re-writing.

You do have good unit tests, right? :)

Brad (
Tuesday, March 25, 2003

As I understand it the point with refactoring is that you should be able to do it gradually. The next time they ask for a feature, maybe you could add some days for refactoring.

David Clayworth
Wednesday, March 26, 2003

As mentioned, refactoring as you go will save you a lot of the "behind the eight ball" headaches. And unit tests will make refactoring easier.

However, even if you have not practiced these two habits perfectly, lightweight development may still be working for you.

My question is, would you really be ahead or the game if you had started with an extensive requirements analysis phase, followed by development of a detailed architecture design?

In my experience, many "heavyweight" projects have just as many headaches. Even if your "clients" think they know their requirements at the outset of the project, things change.

And unless your application strongly resembles another you've already written, you will discover things during implementation that you hadn't considered during design.

It's easy to blame yourself: 'poor analysis', 'insufficient architecture', 'poor implementation', and 'lack of unit tests' are all code phrases for "the religion is sound, but the follower has sinned."

I'd prefer to say your work may be good enough given the vagaries of real life and the time you've already invested. Now you want to refactor. Don't go too far: if the application delivers value, remember that to some extent it already "works"!

Reginald Braithwaite-Lee
Wednesday, March 26, 2003

+1 for up-front planning just not working.

The XP planning process is the best I've ever seen. It's nimble enough that the customer can adapt the needs of the application at will, while still having a functional application at the end of every iteration (2 weeks for us). I've never used a system that was so effective before.

Of course, it requires customer participation (in most cases, the "customer" is going to be someone internal representing the actual customer, like a product manager).

Brad (
Wednesday, March 26, 2003

Brad I would just like to state for the record that I am jealous of your desktop setup. That being said, nice blog ;-)

Wednesday, March 26, 2003


I work at home 4 days a week (CTO for a startup pure software company in Colorado), so a good desktop environment is absolutely crucial to working.

That said, nothing spoils like dual LCDs and kick ass speakers. :)

Brad (
Wednesday, March 26, 2003

Have you considered posting this question to:

Among others Kent Beck, Ron Jefferies, and Robert Martin post there.

If you decide to re-post your question there, I hope that will you do a follow up post in this forum.

One Programmer's Opinion
Wednesday, March 26, 2003

    Now, with XP programming, i'm supposed to only program to what i'm given, not "over design", and just get results.  The problem is, now that i've gotten into the pattern of delivering quick results in a "fix it quick" type fashion, i'm stuck.

I think the idea in XP is to get results first, but still have a simple design. When I first started trying out XP I had a strong temptation to go with the first thing that worked. Those designs were "simple" because we hadn't put a lot of work into them - and we had test cases so we knew they worked! After more practice I realized that simplicity encompasses much more than just the initial design effort.

I probably spend a little more time refactoring than I do adding new features. But my goal of each hour spent refactoring is to gain at least 1 hour back from adding new features in the VERY near future. Sometimes that doesn't work and I end up wasting an afternoon or two. Other times it works really well and I finish in an afternoon what I thought would take a week!

Thursday, March 27, 2003

There's nothing intrinsically wrong with "the first thing that works", especially when you're not sure what's going to work and what's not. That's what refactoring helps you cure later (perhaps immediately after you have something working).

Brad (
Thursday, March 27, 2003

*  Recent Topics

*  Fog Creek Home