Jon Udell writes about personas and points be back to an blog entry he wrote a while back about a well-covered topic (though he recognized this in the end by providing a link to a google search on his entry’s title).
My favorite quote form the article was:
It’s extreme design versus extreme programming. I don’t buy either one completely. Call me an extreme anti-extremist. Call me a bundle of contradictions. There’s more than one way to do it. I’ll never sign up for a methodology, no matter whose. But I’ll learn what I can from all of them.
He points out an interesting contradiction between Extreme Programming and Interaction Design (“Extreme” design). The former school promotes interative discovery. The latter school promotes a complete up-front thought process about the problem domain which is aimed to produce a complete specification.
The google link points to an article specific to this topic in which Kent Beck (of XP fame) and Alan Cooper (of Interaction Design fame) defend their philosphies. The article is called Extreme Programming vs. Interaction Design
In the article, Copper explains how XP is a developer’s self-defense against problems in the organization. Rather than try and solve the problem through the tenets of XP, Cooper would rather fix the organization. Cooper says,
I think XP has some really deep, deep tacit assumptions going on, and I think the deepest tacit assumption is that we have a significant organizational problem, but we can’t fix the organization.
Beck holds fast that all of the interaction analysis doesn’t have to hold up the production process. He contests that once the customer sees what has been created, they can tell you what’s right, what’s wrong, and what needs to happen.
Cooper’s main point is his assertion that the customer cannot give the correct answer. Cooper says,
This is one of the fundamental assumptions, I think, that underlies XP—that the requirements will be shifting—and XP is a tool for getting a grip on those shifting requirements and tracking them much more closely. Interaction design, on the other hand, is not a tool for getting a grip on shifting requirements; it is a tool for damping those shifting requirements by seeing through the inability to articulate problems and solutions on management’s side, and articulating them for the developers. It’s a much, much more efficient way, from a design point of view, from a business point of view, and from a development point of view.
Fascinating.
I can’t help but to raise the glove of Alan Cooper. Even though the two tried to kiss and make up in the end, they got back into a fight and Kent Beck just seemed desperate to validate the code-right-away philosphy. Alan Cooper’s lets-just-think-about-the-problem approach seemed to much more rational to me.
I say that with one caveat, though. IMHO, The waterfall approach is fundamentally flawed and my agreement with most of what Alan Cooper says does not in any way imply I approve of long discrete phases of development. It’s damaging for a developer to work on a recent bug in code he wrote months ago. There is information and understanding achieved once development begins.
When Kent Beck and Alan Cooper were both charged with finding a way their philosophies could interoperate, it was Alan Cooper’s description that seemed to make more sense to me. Read the article and tell me if you disagree.
Posted by Nick Codignotto at May 17, 2004 03:15 PM | TrackBackIt is obvious that some design is needed. The question is how much design do you need to do up front?
I think the answer is predicated on how hard is it to change that thing?
If it takes six weeks to get a change put through, then you need to design the heck out of the feature. If it takes six minutes, then you can forgo a lengthy design.
When we do go to modify that six-weeks design, we should think about how to refactor the code, so that the change-able part is exposed in a way that we can easily grab onto it. When the next change inevitably comes, we can easily change this design.