Bill Venners: plan for the future, to design for reuse
Would that be the future six-months, or the future this week? Planning for something just-in-case it might happen, is surely different than planning for something that is part of this iteration but not part of todays work.

We understand that planning with a six-month time-horizon has much more risk than planning with a one-week time-horizon.

Bill Venners: At the beginning, you don't understand the problem enough to know what to design. You discover a lot about the problem space by implementing the code. Coding is almost like exploring the space.
Language is so fluid - just 30 years ago, "coding" was taken to mean an almost mechanical translation of design to something a computer could deal with.

"The creative activity of programming - to be distinguished from coding... It is here considered as a sequence of design decisions concerning the decomposition of tasks into subtasks and of data into data structures."

Program Development by Stepwise Refinement
http://www.acm.org/classics/dec95/

Bill Venners: Grandma Moses
And we know that many great artists use multiple design studies, and then sketch in perspective grids, position and reposition figures, before they start painting. Was Grandma Moses painting the same painting over and over again?

Time you spend thinking about tomorrow is time you're not spending thinking about what to do today.
True, but not necessarily wasteful.
If tomorrow really is Tomorrow (rather than some distant future), not looking-ahead for possible interactions could be considered to be working blind.

Nobody says, "Make a master plan for the page. Figure out what paragraphs are going to do.
There's a huge difference between personal letters (which mostly exist as a form of self expression) and other forms of purposeful writing.

Cunningham: I love computer graphics, but every system I've seen to try to turn programming into pictures has lost that syntactic element. There's something about syntax that makes it very precise for reading.

Agreed, I never could understand the hype about UML. Maybe it's because I came from a hardware design background where we made the transition from using graphical schematics to textual hardware design languages back in the early to mid 90's. The whole move to UML seems backwards. A textual description is a lot easier to deal with than graphics; It's very difficult to grep for something in UML for example and how do you parse a picture?. That being the case, it seems more sensible just to use your programming langauge.

Bill Venners: If you don't spend that other time designing?

The implication of this question is that programming and designing are two distinct activities (that when you're doing one you can't be doing the other). Though Ward didn't say so explicitly, I get the impression that he's saying that designing and programming don't need to be considered seperate activities. The more holistic approach is to consider them (and do them) together.

I once worked in a corporate environment where the two activities (programming and design) were totally divorced from each other. The boss said that she should be able to write up a detailed spec for the design and then hand it off to low-level code monkies who would implement it exactly to the spec. She required a 50 page document prior to writing a line of code and prototyping was _not_ allowed. I found that as a result we were producing brittle code that was not easily adaptable as the situation changed. We were always behind schedule as we had to take so much time just preparing the design document up front. And when the design document was completed it was considered to be written in stone; it would take an act of congress to get it amended even if you discovered that the document was seriously flawed in the course of doing the implementation. As this system became more and more entrenched I found that I just couldn't develop software in that kind of environment. I didn't know anything about XP or the Agile development movement then, but it seems that I was already thinking along those lines since I liked to prototype and do design and development together in smaller chunks. Unfortunately, at the time, I thought that it was somehow a problem with me and that I must somehow be doing it 'wrong'. Now I know better.
Thanks Ward, Kent and others in the XP/Agile development camp; you're setting us free.

"If we write 10 programs a day instead of one program every 10 days, we just get that much more experience."

This is a curious statement. Are we basically talking about processes that relate to problems of such simplicity that programs can be turned out at the rate of 10 per day?

Maybe I'm slow (OK I admit I am, compared to some) but I can't imagine turning out a commercially useful program in 48 minutes (8 hours/10) and repeating that 10 times in a day.

Vince.

As reflected in the interview, extreme programmers like the principle of 'You aren't gonna need it'.

I note that the originators of XP are also use Smalltalk.

Do you think that Extreme Programmers sometimes fail to see the limitations of there methodology. For example, I do not see how the XP approach could have ever produced Smalltalk.

In smalltalk everything is an object, including basic types such as integer. This strikes me as a big vision thing. If XPers were developing Smalltalk (in a pair, of course) I would imagine the conversation would go something like:

"We need to add together 2 numbers"
"OK, lets write an Integer object, I'll start on the tests."
"Why?"
"We always test first."
"No, I mean why develop an Integer Object. Integers are bytes, not objects."
"Yes, but shouldn't everything be an object."
"Even integers?"
"Yes."
"Are we going to need it?"
"It would be nice."
"Can we add these two numbers together without an integer object?"
"Well, yes."
"Then you aren't going to need it."

The Smalltalk environment strikes me as the product of some very high level thinking, the type of up front design that XP dismisses as unnecessary.

I would say that this type of forward thinking design created Smalltalk and OO as we now know it. The flexibility of that type of environment is what made the agile style of development possible. The only reason that XPers are able to take there approach is the support of the framework they work in.

They were able to use this support because it already existed, it was built into Smalltalk long before any of them ever even realised they might need it.

Certainly, there are problems when this type of up front design causes problems when applied to an unsuitable task.

However, I'm sure we will also find situations where trying to apply the XP methods, when up front design is needed, will also cause problems.

>To worry about tomorrow is to detract from your work today.

This is almost like a play with words and logic.
*Thinking* about tomorrow (or the future) is not the same as *worrying* about tomorrow. One is clearly a negative view of it.

>Time you spend thinking about tomorrow is time you're not >spending thinking about what to do today.

Well, that's ok, because you saved time yesterday when you thought about today! :-)
It's just like instruction pipelining!

It just sounds like a play with words for not having to plan for the future. People are lazy by their nature, but sometimes it's good to do some work now to avoid making work in the future, but as with all things, having a balanced view is better than being extreme in any direction. (There was a mentioning of Zen, think of Ying/Yang)
Being extreme is easy, you don't need to balance...

>There's something about syntax that makes it very precise >for reading. I love photography. A photograph will tell a >story. But words tell a story even better. Words are more >versatile. You can paint a verbal picture that's much >richer than you can photograph.

Syntax is the grammar, structure, or order of the elements in a language statement.
What do you mean by saying it makes it very precise for reading?

Ward, you draw very strange conclusions about words and pictures. How can you say that words are more versatile, for whom are words more versataile?
Words and pictures will tell different storys for different people, words in particular mean very different things to different people depending on culture etc, but pictures
on the other hand usually can communicate feelings across cultures.
It's interesting that you use words to 'paint'! This probably means that you internally create pictures when you read words, and will experience this as telling the story better as you get to chose the pictures!


>Grandma Moses didn't paint that way.

Well, first of all we don't know what Grandma Moses paintings looked like!
And if you draw the parallel to puzzles. Try assembling a
puzzle without know what the final picture will look like!


I'm not against XP, I think there are many good things to learn from it. Still I get the feeling it is better applied without the 'extreme' part of it and what it really wants to convey is the 'get dirty and get the work done' idea.

Speed. I can think and scribble at a high level much faster
than i can code. If i am wrong so what. In XP you are always wrong because the next user story changes whatever your did before, so being wrong isn't a problem.

Complexity. Let's discuss our clustering system by writing code. Don't think so.

Appropriate level of abstraction. Code is at one level abstraction. Instead of following simple rules why not use your judgement about what will work best for what you are trying to discuss. Sometimes that is code. Sometimes it is not. The code only is like being shown your DNA instead of an xray of your broken bone.