Achilles is a well-known software architect; the Tortoise is a famous XPer. Today they’re talking about design in XP.

Achilles
Really Mr. T, I thought that you were smarter than that; you can't produce software without designing it first.
Tortoise
I agree totally.
Achilles
What?
Tortoise
I said that I agree with you. It's foolish to think that you can develop any non-trivial system without first designing it.
Achilles
But I've heard rumours that you don't do design.
Tortoise
Totally unfounded.
Achilles
But the rumours?
Tortoise
You shouldn't listen to rumours.
Achilles
Okay, prove it, show me the UML diagrams from your current project.
Tortoise
We don't use UML on our project.
Achilles
Alright then, fair enough, not everyone uses the 'Universal Standard', you can explain your diagram standard as we go, where are the diagrams?
Tortoise
We don't use many diagrams, and the ones we had, we threw away just after we'd created them.
Achilles
What?
Tortoise
Achilles my friend, there seems to be something wrong with your hearing today, perhaps you should visit the apothecary.
Achilles
I think that you're right. I thought that I heard you say that you don't have any design documents for your current project!
Tortoise
Hmmm, well, you probably don't need the apothecary then, your hearing seems fine, for that is what I said.
Achilles
I don't believe that you could be so dumb, you of all 'people', if you haven't got any documents, then you can't have done any design.
Tortoise
Interesting... You think that the result of design is a document?
Achilles
Of course it is.
Tortoise
You are confused, perhaps the apothecary is called for after all, run along, tell him that you're confused, and he'll set some leeches on you, that should help.
Achilles
I'm not going to the apothecary to be leeched, just because you're being obnoxious. Now, you obviously don't think that design produces documents, so what does it produce?
Tortoise
S O F T W A R E
Achilles
<coughs> Software? Of course it produces software, but <speaking very slowly, as if to a child>, without the design diagrams how do the developers know what software to build?
Tortoise
Don't talk down to me Achilles, you may be Greece's greatest athlete, but that doesn't excuse bad manners!
Achilles
It's hard not to talk down to you; you're only 1 cubit high!
Tortoise
<tuts>
Achilles
Okay, sorry, it was wrong of me, and I should know better, you're always right, but I think that I've got you on this one, how do your developers know what to build if they don't have the design documents?
Tortoise
That's better, a bad attitude won't get you good answers. I'd like to answer you with a question.
Achilles
I thought that you might.
Tortoise
Why?
Achilles
You always do.
Tortoise
Oh. Well, what do your developers do with your design documents?
Achilles
They read them.
Tortoise
And then?
Achilles
They build software, following the design.
Tortoise
Really? If it's that simple, why do we need programmers?
Achilles
Because it takes a thinking mind to understand the designs, and turn them into code.
Tortoise
So, they have to understand the design before they write the code.
Achilles
Of course.
Tortoise
Well then, there's your answer.
Achilles
Your developers understand the design, and so don't need the documents?
Tortoise
I think that you understand now, well done.
Achilles
Wait a minute, it's not that easy. How do they gain this understanding of the design? Who does the design?
Tortoise
The developers gain an understanding of the design, by doing the design themselves.
Achilles
<thinks, and then replies slowly (but not pedantically)> Okay, if the developers do the design themselves then you don't need the diagrams to communicate it to them.
Tortoise
Right.
Achilles
But there are still problems.
Tortoise
Are there?
Achilles
I think so. For most modern, non-trivial systems, the design is too big to hold in a single persons head, so surely you'll need design diagrams then?
Tortoise
What would need to be true for this not to be the case?
Achilles
Well, the system could be small enough for one person.
Tortoise
Right again, so, we make our systems tiny. We only create a very small bit of functionality at a time, so our design stays small.
Achilles
But the whole system isn't small, you may be coding little bits at a time, but you've still got to design the whole system first.
Tortoise
No, actually you don't. In fact, judging by the amount of mistakes people make, it appears to be impossible to do a good job of designing a system before it's built.
Achilles
But you can't design a system after it's built.
Tortoise
No, but you can design one, whilst it is being built!
Achilles
How does that work?
Tortoise
Production tasks are very small, usually no more than a couple of hours work. This is a very manageable chunk of work, especially as we ensure that two people are working on it. As the developers sit down to write the code, they spend a short while thinking about how to do it, and discussing it between themselves.
Achilles
And that's the design activity, you do a little bit of design, and a little bit of coding? It's like iterative development, but on a much smaller scale.
Tortoise
Yeah, that's part of it.
Achilles
What's the rest?
Tortoise
Once they've got an idea on how to implement the feature, they start by building a single test for part of the feature, and running it.
Achilles
But, without the feature there, surely the test will fail. Isn't it a bit stupid to build a test you know is going to fail?
Tortoise
Not at all, that's just the way we work. We don't write any production code unless we have a failing test first.
Achilles
So, you aren't writing code, you're writing tests, and then fixing the code.
Tortoise
That's right. We test, and fix, one small test at a time. Often we find that our tests lead us away from the direction we'd decided upon in our short design session, and that's okay, we let the tests, and the code, lead us where they must. We call this Test First Design.
Achilles
But surely this just makes the whole codebase a mess.
Tortoise
It would, except for the final part of our design strategy.
Achilles
The final part? Go on then, I can see that I'm beginning to lose this argument.
Tortoise
We start by writing a test, then we write code to pass it. As you so rightly say, this can make a bit of a mess in the overall system, so we visit the apothecary.
Achilles
You what?
Tortoise
We visit the apothecary, technically it's called refactoring, but we like to think of it as a visit to the apothecary. If you've sustained an injury in the stadium, say you got hit by another athlete's discus, you'd go to the apothecary and have the wound seen to, otherwise it would go all smelly and horrible.
Achilles
And if it wasn't for you I wouldn't have known to do that, thanks, I couldn't do with loosing another toe.
Tortoise
My pleasure, where were we?
Achilles
The code apothecary.
Tortoise
Ah yes, that's right. We take the code to the apothecary. Really we refactor it. Did you know that someone once called refactoring the most powerful concept introduced in the last two thousand years of software engineering?
Achilles
Is it?
Tortoise
Probably.
Achilles
Tell me more about it then.
Tortoise
Refactoring erases the smelly wounds that new code inflicts on a system. Following some well known rules it's possible to remove most duplication from a system, and to increase its modularity, both of which are very desirable traits.
Achilles
Desirable traits yes, but is it good design?
Tortoise
Well, if a good design is one which exhibits desirable traits, then something which exhibits desirable traits must be a good design, no?
Achilles
No... Well, yes, that is, er, I don't know.
Tortoise
I realise that Achilles, if you knew that most of your projects wouldn't have failed.
Achilles
But is it really good design?
Tortoise
Recently a group of the world's top software engineers held a debate on the subject"What is good design", do you know what the result was?
Achilles
No, but I imagine that it was very profound and technical.
Tortoise
Actually, the best they got was "A good design is one that doesn't suck!"
Achilles
What?
Tortoise
There you go again, these exclamations have become boring now, I'll ask the author to put more intelligent words in your mouth from now on.
Achilles
What I meant to say was, is that it? Couldn't these noble cognoscenti come up with anything better?
Tortoise
No, the problem is the context is too big. Most of these people could recognise a good design if they saw it, but the context is too big for them to give a more prescriptive answer.
Achilles
How does that help us? Does it help us?
Tortoise
It helps us see that your question, is it good design, should properly be answered Mu.
Achilles
The Zen, "Unask the question", the question has no meaning.
Tortoise
That's it, you're learning.
Achilles
So, we can't ask, does refactoring produce good designs, because we don't know what constitutes a good design.
Tortoise
Right.
Achilles
All we can say is that it produces designs with desirable features.
Tortoise
Right again.
Achilles
Cool.
Tortoise
You think that in this Mediterranean heat I could be cool whilst wearing a huge shell?
Achilles
No, I meant, that sound good, but you still haven't explained how your developers can understand the design of a whole system.
Tortoise
This is easy, they don't.
Achilles
But it they don't understand the design, who is controlling it.
Tortoise
The code is.
Achilles
I don't really understand that.
Tortoise
Refactoring is guided by 'smelly' code, that's code that has elements of bad design. Remember, we don't know what's good or bad, but we can recognise it when we see it. When we see terrible code we say that it stinks, well, when we see code that isn't terrible, but isn't too good, we say that it smells (we wouldn't want to mix metaphors now would we).
Achilles
Okay, the code controls the direction of evolution, and I guess that since code is added from requirements, then it's ultimately driven by business needs. But how do your developers know the whole design of a non-trivial system, when most other developers can't?
Tortoise
That's easy, they don't.
Achilles
How does this work then?
Tortoise
Each developer knows the whole system, from a high level. Each developer also knows the parts she's worked on, in detail.
Achilles
But what if your work takes you into an area of code you don't have any detailed knowledge of?
Tortoise
What would you do, if you had no design documents, and were working on code you weren't familiar with?
Achilles
I don't know? Ask for help I suppose?
Tortoise
Exactly, and that's precisely what we do, we ask for help. A developer who can help us will come over, and help us out, they'll pair with us, until we have enough knowledge to proceed, or until we've finished.
Achilles
But won't that interfere with the other developer's, lets call her Y, won't that interfere with Y's work?
Tortoise
Yes.
Achilles
But then their work won't get done.
Tortoise
Why not?
Achilles
Because they've spent all their time with the developer who needed help, let's call her X.
Tortoise
But, with help, X will finish her task much sooner, so the time lost to Y is made up by X, overall, it balances out.
Achilles
I'll take your word for that, because I don't want to go into details about pair programming at the moment.
Tortoise
Good, you'd end up defending it yourself by the end of the conversation.
Achilles
So, I've found that you do a design activity, frequently, and that your software is designed well.
Tortoise
Exhibits features that are desirable.
Achilles
Yeah, whatever... You do do design, and your software is designed well.
Tortoise
That's it, and I believe that you've got your answer, does XP do design? Yes, and we do it very well.
Achilles
Are there any other benefits of this approach.
Tortoise
Lots, think about a six month project that gets cancelled after three months.
Achilles
I've seen a few of those.
Tortoise
Me too. Tell me your most recent.
Achilles
We'd gathered the requirements, and had just finished the design. We were well into building the infrastructure, and then we had to throw it all away.
Tortoise
Did the business get any benefit from it at all?
Achilles
Well, we all got more experience, and when we all started complaining they told us to treat it as a learning experience.
Tortoise
Learning has been defined as experience that produce a permanent change in behaviour. Did you run your next project any differently?
Achilles
Are you suggesting that we didn't learn anything?
Tortoise
No, I was asking a question.
Achilles
<sulkily> Good.
Tortoise
Did you?
Achilles
Did we what?
Tortoise
Did you learn anything?
Achilles
<defiantly> We did!
Tortoise
Did you act any differently?
Achilles
No.
Tortoise
Did you learn anything?
Achilles
<sulkily again>No.
Tortoise
There you are, that wasn't so difficult.
Achilles
I suppose things would have been different under XP?
Tortoise
You tell me.
Achilles
Well, if you're only doing design as it's needed I suppose that means that you would have started coding a lot earlier.
Tortoise
Probably in the first week.
Achilles
And if you're only coding units of business functionality, as opposed to infrastructure, then you'd produce software that was useful to the business; how soon could you do that?
Tortoise
After about three weeks, at the most, usually after a week or two, but it may take slightly longer in the first couple of iterations, because of the problems of learning our way into the project.
Achilles
So, you'd have something of value delivered to the business, after say two weeks (that seems a happy average).
Tortoise
We would.
Achilles
And because of your revolutionary design techniques this system would be well designed.
Tortoise
We prefer to drop the R.
Achilles
I don't understand?
Tortoise
It's not Revolutionary Design, it's Evolutionary Design.
Achilles
Whatever.
Tortoise
The design evolves along with the needs of the business.
Achilles
Okay, you release a well designed system early, and I suppose the tests make it high quality too.
Tortoise
They help, yes, but we have other practices which also help with this.
Achilles
So, in a cancelled project scenario, I come out with nothing but expenses, whereas, with XP because of evolutionary design, the business has been getting benefit from the software from the end of the second week of the project, and every two weeks after that they get an increment in the software that delivers more useful functionality. After six months, they've had twelve releases, and every major feature they've requested is present. They may as well cancel the project then.
Tortoise
Exactly.
Achilles
Sounds good, where can I learn more?

Our protagonists walk down the path into history, the world’s first software developers to try XP (and Kent Beck reckons he invented it, ha).