Kent Beck vs. Alan Cooper

xp vs interaction design interesting debate ...

Fascinating. But I do hate sites whete they make you page through 10 short chunks rather than letting you just print out the discussion. Grr.

Very interesting, indeed. I wonder though: has anybody ever worked for or know of any organizations that actually do "Cooperesque interaction design"?
Junilu

interesting.

Originally posted by David Peterson:
For those who don't have time to read the entire article, the gist is...

Beck believes XP is the answer because this way the customers have complete control over what goes in the product and therefore get what they want.

Cooper believes that customers don't necessarily know what they want and that typical customers will simply try to automate the tasks they presently do. However, by taking a step back and looking at the bigger picture (which XP tends not to encourage) and looking at end goals with an experienced 'interaction designer' they could come up with a superior solution which the customers would not have come up with on their own.

David

XP doesn't (yet) discuss how the customer gets to his first vision of the desired system. XP also presumes that the vision will change while the customer sees the system grow. It builds on the implication that it is therefore essential to show the customer a running system early and often, so that she can evaluate its usefullness and learns what she really wants. Probably this process can be accompanied by cooperesque interaction design.
Cooper seems to suggest that "big up front" interaction design is the best way to "get the vision right" before development starts. He seems to fear the "exponential change of cost curve" to be invoked by changing requirements.
XP promises to flatten this curve by using a specific set of pracices (mainly targeted at holding the code simple and mobile). Beck seems to be very interested in an experiment of joining XP and interaction design. I think this would be a very interesting experiment - probably everyone would learn something from it.

I wonder though: has anybody ever worked for or know of any organizations that actually do "Cooperesque interaction design"?
Any software developer actually does it. Cooper's points are:
1) "customers cannot articulate what it is they want, nor can they evaluate it when they see it."
Who can argue with this?

2) "neither customers nor developers are properly equipped to solve the problem."
In my experience, developers (experienced) are equipped better, so they take on the challenge. Unexperienced developers will follow customers requirements closely, experienced developers know that to do so is to ask for trouble. Motto of experienced developers is "customers will get not what they want, but what they need"

Problem with such an approach is that it's still a dilettantish approach, grounded in their limited experience rather than formal education. What Cooper proposes - to have a team of specially trained people, interaction designers, - makes perfect sense.

Originally posted by Ilja Preuss:
XP also presumes that the vision will change while the customer sees the system grow. It builds on the implication that it is therefore essential to show the customer a running system early and often, so that she can evaluate its usefullness and learns what she really wants.

Yeah, that's what Cooper calls "automating the pain". The customer will check how well her pain is implemented.

In my understanding, interaction design's mission is to free programmers from implementing the pain.

In talking with some folks at OOPSLA, I have found that people who are working on backend systems are having a better experience with XP than folks working on front-end systems.
To develop backend systems, all you need to do is drop a "testme" method into all of your classes to test your code. To test an interface there is a lot more work in developing the code itself as well as manual or automatic test cases.
I think what Allen is trying to say is that with a bit of foresight you can cut down on a lot of the work that goes into developing and testing an interface. His "interaction designer" isn't concerned about what a dialog box looks like, she is concerned whether a dialog box should exist at all. At this level, refactoring could easily become rewriting, and therefore cost more.
There is a balance; each team lead has to find that balance.
Larry Constantine as attempted to merge these two concepts more formally in his paper onAgile Design

To highlight Mr cooper's point.
I would like to share a experience on a project that I worked on several years ago.
We were developing a system for a brokerage firm. Customer orders were being faxed around various departments(sales,mid office, trading, compliance ...) and we had to build a system to replace the fax based system.
Since none of the experienced C++ middleware programers wanted to be bothered with such trivial details like the user interface :roll: , the task was assigned to a bunch of programmers fresh out of college.
The users/programmers simply replicated the fax forms

on to the computer screen resulting in a lousy interface and a very unusable system.
When I joined the project and attempted to suggest changes the users simply rejected them.
They had gotten used to the various quirks of the screens, and that was the only way they wanted to see them. We spent a lot of time writing code to make the system behave in strange kinds of ways
All this could have been avoided and a lot of time/effort/money/bugs would have been saved if somebody with basic UI building skills had spent some time educating the users(and developers).
I do agree with some parts of the XP methodologies and have used some of them in my projects. But it does take a person with vision to build a good system.
The more thought you can spend upfront in trying to sort out the details and documenting them the better your system is going to be. Requirements do change and not everything is clear upfront,but I do belive that's a poor excuse for not spending time on design.
[ February 19, 2002: Message edited by: Ravi Veeraghanta ]

Originally posted by Rob Keefer:
In talking with some folks at OOPSLA, I have found that people who are working on backend systems are having a better experience with XP than folks working on front-end systems.
To develop backend systems, all you need to do is drop a "testme" method into all of your classes to test your code. To test an interface there is a lot more work in developing the code itself as well as manual or automatic test cases.
Larry Constantine as attempted to merge these two concepts more formally in his paper onAgile Design

Rob,
Your views are heuristic. Thanks for your recommendation of Constantine's article. Its very interesting.
Constantine criticizes that Agile methods ignore UI design. Your thoughts?

Originally posted by Doug Wang:

Your views are heuristic. Thanks for your recommendation of Constantine's article. Its very interesting.
Constantine criticizes that Agile methods ignore UI design. Your thoughts?

Doug,
Yeh, now that I re-read my post, in trying to be brief, I did fail to share my own experience and how I came to these conclusions ...

I worked on two XP projects developing communications software. Both projects were successful (i.e. met schedule, budget, client expectations, etc.)
Then I was chosen to work on a web project. Since we had some success with XP previously, we thought we'd try it again. For me, using XP to develop a UI was much different than developing comm. software. After a couple false starts, I began to look around to see if others were having similar experience, and that is when I found the Agile Design paper by Constantine.
I am surprised you thought him critical of AM. I see this paper trying to fill a hole that XP leaves as an exercise for the reader.
The process that Constantine describes in this paper worked fairly well for me on the web project. The most useful part was designing the interaction (vs. functionality) for a small story. The part that was more frustrating was the overall lack of architecture - the consistency that good UI's have (elegance, maybe?)
It's this elegance that Constantine and Cooper both advocate, and both seem concerned will go away when folks use AM.
- Rob

Wow, great article. I wish I could have been a fly on the wall there.
I tend to side with Alan Cooper, as I don't have much faith in XP. However, I think what Alan is proposing has serious risks. One mistake we often make as engineers is we think we're smart. If we start looking at other organizational behavior, we start to say, "well, why don't they do it this way, that makes more sense." Sometimes we don't see the whole picture. Even if we do see a better for our customers to work, they have a lot of momentum, in their person, in their organization, in their industry. It may not be so easy to change their behavior. Consequently, we must remember that the customer is always right, and they are often overall happier doing it they way they want, made easier by our tools, rather then, they way we want, which may be easier for us, and overall more efficent, but not what they are used to.

--Mark

To challenge or not to challenge is a difficult balance. Cooper favours "to challenge", XP favours "not to challenge".
I'm with Cooper - with a bit of luck, a customer who is broad-minded enough to use an agile development method will also be broad-minded enough to accept there may be fundamentally better ways to do the things they do.
David

Originally posted by David Peterson:
To challenge or not to challenge is a difficult balance. Cooper favours "to challenge", XP favours "not to challenge".

I don't understand - could you please elaborate?

I'm with Cooper - with a bit of luck, a customer who is broad-minded enough to use an agile development method will also be broad-minded enough to accept there may be fundamentally better ways to do the things they do.

There is no "versus" here (in fact it seems to me that Beck is with Cooper too in this regard). It's just that agile processes make it possible to *incrementally* implement and explore these "fundamentally better ways", instead of "big up front".

The problem is that XP avoids looking at the 'bigger picture' and therefore may miss opportunities to challenge and simplify the underlying processes (perhaps even eradicating whole swathes of bureaucracy).
Cooper: We're working with companies right now that have 50 or 60 internal departments, each with a Web presence. ... How do you get them working together? If you go to the customers, have a whole series of discussions with them, then build what they want ... you're going to end up with a really well-constructed white elephant that doesn't solve their problem. Their problem is, they have to integrate information and their company at a much higher level.
By focusing on dealing with one step at a time you don't notice there's an elevator in the next room.
I'm not advocating big up-front design, but I do favour doing more and wider-reaching analysis and challenging the customer's assumptions.
David
[ February 21, 2002: Message edited by: David Peterson ]

Originally posted by David Peterson:
The problem is that XP avoids looking at the 'bigger picture'...
[ February 21, 2002: Message edited by: David Peterson ]

I disagree. XP does not attempt to be all-encompassing. Its focus and applicability is more on the production and delivery of working code which is not the only area of activity in software development.
As developers we should know what techniques are available and where they are applicable. We should not limit ourselves to a single technique and we should be careful in trying to use them for purposes other than those for which they were developed.
I don't think that using XP practices precludes the use of other compatible practices. Beck even says that he thinks that employing Cooper's interaction design methods in developing XP user stories would be "kick-ass".
Like Ilja said, there is no "versus" here.
Junilu

Originally posted by David Peterson:
By focusing on dealing with one step at a time you don't notice there's an elevator in the next room.

A typical XP Release Planning Meeting covers development of half a year and more. It's only the *development* that is done one step at a time.

I'm not advocating big up-front design, but I do favour doing more and wider-reaching analysis and challenging the customer's assumptions.

In the XP terminology, this is the job of the Customer (notice the capital "C"). The Customer role may actually be filled by a team of business analysts, acceptance testers and - guess what - interaction designers. This is an area, where XP is rather vague (as yet).

I stand corrected!
David