Fog Creek Software
Discussion Board

Question about XP and Test Driven Development...

Most readers will probably notice that this was a topic on Tuesday's Slashdot. 

Anyway, my question does this work?  Maybe my understanding is flawed (actually, I'm willing to bet money it is), but how is it possible to test code and provide incremental releases without some upfront design work?  From my limited understanding of XP, the methodology seems to poo poo detailed upfront design work in favor of incremental tracer bullet approach.  But I just don't see how you can know where to go if you don't agree to some sort of vision in the first place.  Also, is anyone using this methodology and how well is it working for you?  Many people who comment on it swear by it.

Eventually I'm just gonna have to buy Kent's book. :)

Wednesday, January 29, 2003

XP doesn't discourage design - it minimizes it to "just enough" design.  Just enough design for you to write the software so that you can make your next release of the product.  You'll get a chance to redesign the code the next time around.

The asumption is that in today's release you're not going to have an extensible peice of code which will handle tomorrow's problems.  However, by the time tomorrow gets here, the problem will have changed enough such that your extensible code would not have handled the problem either.

I think this is a very valid argument.  There is always too much to do - too much work in too little time.  Therefore, code to what the current release feature set is, nail it down, and ship it.  You'll learn more in a shorter time with your product out there, than you would trying to anticipate how to extend the design to be future proof.

Its not that you don't design - its just that you don't let your design get ahead of your release objectives (which are enumerated in the user stories).

Full disclosure: I've never done XP, but I've read several of Beck's books.

Nat Ersoz
Wednesday, January 29, 2003

I have been involved in 3 product releases using XP, for whatever that's worth.

It's a common misunderstanding that XP "discourages" up front design. The difference is, we do just enough design. When you get to a point where implementation details, market changes, whatever, are likely to make further design obsolete at some point, then you stop.

We actually design 3 stages. When we pick the stories for a release, we do a high level design, enough that we can estimate the stories accurately. When we pick the stories for an iteration, we do enough design to be able to estimate the tasks accurately. Finally, when a pair of developers works on the tasks, they are constantly doing design. Test first (or test driven) development helps you think about the design before you start banging on the keyboard.

A lot of developers take the waterfall approach of a huge up front design document for granted. What they don't realize is that this is really an artifact of early military projects where there was a hardware component as well as a software component. Often the hardware component was being built from scratch and the software guys had little or nothing to do until the hardware was delivered. What do you do with a bunch of guys with nothing to do? Well, you might as well get them to work on design.

However, no ones ever done any serious study (AFAIK) to determine what percentage of these up front designs actually made it through implementation unaltered. Very few, I suspect. So, if you know your almost surely going to have to change your design one or more times during the project why invest large amounts of effort up front? The trick is learning/knowing what is important and what's not.

XP isn't perfect by any means. We're finding that it doesn't scale well to larger groups. We've had virtually no problems with pair programming which is one of the more controversial practices in XP, but I've heard of programmers who absolutely refuse to do this. As always, your methodology is not a suicide pact. You have to take what works and be willing to change what doesn't.

Bruce Rennie
Wednesday, January 29, 2003


So it sounds like the emphasis is on *just* enough design and then building the product.  I like that.  However, do you ever worry about cases where bad design ideas, ideas that would have been caught by a more detailed design, go through to the coding phase where they are much more costly to fix? Or is this a nonissue?  I guess that's somewhat the reason I'm stuck in the "overengineering" mindset. 

Wednesday, January 29, 2003

Yes, it's a non-issue.

The entire "theory" of XP is that cost-of-change curve is NOT exponential when doing XP - it's fairly flat.

The presence of strong unit tests to tell you when you've broken something, plus continual refactoring (to make the code easy to change) means that it's not expensive to redo design.

The idea is that if you find something that's hard to do, rather than diving in and writing 5000 lines of code, stop and think about the system a little. What needs to change to make this feature easy to do? Then refactor to make that change. Then add the new feature.

At least in theory - I unfortunately haven't had a chance to work on an XP project. Most of my "teams" have been 1 or 2 two people. Rather hard to swing XP on such a small project.

Chris Tavares
Wednesday, January 29, 2003


We worry about bad or missed design decisions all the time. Who doesn't? The point I would make is that this is a problem with big up front design as well. Anyone who says they can anticipate ALL possible aspects of a design ahead of time is lying. The big up front design may very allow fewer missed design decisions but, for the same reason, it will also waste time on design that is rendered obsolete or irrelevant by changing situations.

I guess there's one point we need to understand: if you're requirements are delivered by God and will never change, then a lot of the benefits of XP go away.

The XP method of doing things resonates with me because I'm a firm believe in the law of diminishing returns. I do believe that there is a point where working to make your design that much more comprehensive actually wastes time.

Finally, I also think there's a lot to be said for getting your team into an "agile" frame of mind, even if you don't do XP. It's a good thing, in my opinion, to have a team that expects requirements change, expects to change the design, and expects to have to change things. Not only expects it, but welcomes it.

Bruce Rennie
Wednesday, January 29, 2003


you may want to try doing XP for one:

Giovanni Corriga
Wednesday, January 29, 2003


Thanks for the link. Looks like an interesting paper!

Chris Tavares
Wednesday, January 29, 2003

*  Recent Topics

*  Fog Creek Home