Cooper Vs Beck contains a transcript of a joint interview with KentBeck and AlanCooper discussing ExtremeProgramming and InteractionDesign.

I would prefer to begin by writing software for people, and only later write it for personas. -- KentBeck on the XpMailingList

I was on a conference call with a project that employs both programmers and interaction designers. One of the programmers said, "I read the article and I really appreciated the way you sounded willing to learn and compromise. Cooper came off as a dogmatic bastard." I was feeling good, for about two seconds, until an interaction designer said, "I read it, too, and I thought exactly the opposite." Sigh... KentBeck

I agree with both opposites. The WhiteBook? and AboutFace are still in my Top 4 most influential book list. Embracing well-articulated conflicting viewpoints is a life well worth living. -- JeffWinchell

It appeared to me at the beginning as two "sales pitches" to the same customer except interleaved with each other, so neither of you were talking to each other (merely at the reader). Midway through you attempted to build a bridge by positing not only a challenge but by suggesting a practical experiment of InteractionDesign + XP, but Alan rejected it rather limply.

The interview was doomed to begin with. Why have two competing methodologists in one interview unless the interviewer wanted to create "conflict"? It's an amateurish journalism stunt, and one that I've found backfires without trust or alcohol (liquid trust). Experienced people don't let their guards down to non-friends, and it was obvious from the interview neither of you did. It was a risk for the interviewer to pull such a lame duck, and it didn't fly. No big deal. -- SunirShah

The interview reminded me of the data-versus-theory dilemma. XP focuses on low-level stories (independent data points) because a big-picture (meaningful theory) is not possible. InteractiveDesign? says that the big-picture is possible and is the only way to succeed in the market. Could InteractiveDesign? be a substitute for the SystemMetaphor? -- AsimJalis

My first impression of the interview was of two alien races communicating through a very poor UniversalTranslator. The language is technically the same, but the concepts aren't connecting very well.

But I end up agreeing with KentBeck most of the time, being a software guy myself.

In some ways, though, I (sort of) agree with what AlanCooper is (sort of) saying:

After reading the article, I can't shake the feeling that Cooper is really looking for a critical niche to fill. The interaction designer would be the new priest of the post-PC generation, replacing the Architect or SystemAnalyst. They would be the keepers of the system, and, like KentBeck said, would be the bottleneck. Cooper mentions that it would be a big effort to do interaction design right, requiring a rework of the entire organization. From my experience, few people in the organization want to change it, and even fewer succeed. XP also wants to change the organization, but at a much lesser scale - getting the developers and customers together, which can be done in a covert manner if necessary, assuming both parties agree. Also, XP seems to be more egalitarian - it pushes more power onto more people, while the interaction design seems to be consolidating more power into a smaller group. -- PeteHardie

I got the feeling that Cooper was both too timid and too grandiose, and Beck was missing an opportunity for XP at the same time. To explain: Cooper is too grandiose in trying to be the boss of everything, but too timid in that "interaction" is still too narrow a scope to get good systems. Good systems need to be good citizens in the environment in which they will actually be used. I don't think you can get good citizens using big design up front. Incremental try-and-adapt (XP style) would work much better. But all that assumes you can get past the "customer representative" and work with the real end users. -- BobHaugen

Cooper's InteractionDesigner is Beck's OnsiteCustomer, with a little extra training in software development. I actually think that might be something worth exploring. -- RobHarwood

Kevin Lawrence on the XP mailing list said the following (which I agree with):

To be fair to Cooper, there are two steps in GoalDirectedDesign? (GDD) that take a fair amount of time that wouldn't generate stories..

These steps do not generate the large BigDesignUpFront-like artifacts that become hard to change. They generate insight into the real problem that customer needs to solve, rather than the one that they say they want to solve (goals vs tasks again). There is very little that comes out of these phases that is actionable by developers. IMO It wouldn't make a lot of sense to try to do this in tandem with development.

The last step

is where the stories come from. This, IMO, could definitely be done iteratively and would benefit a lot from doing it that way.

One idea that is maybe worth exploring is that system-oriented stories and spiking that could be done before the user-oriented stories (generated by GDD) are ready ... but this would seem to violate the principles of both XP and GDD ... doing things that, potentially, don't deliver value to the customer because they require crystal ball gazing.

One thing that you did an admirable job of trying to explain, Kent, but that Cooper seemed to refuse to accept was that XP makes the resulting system less rigid, more malleable and therefore easier to change. Cooper was coming from a place where programmers build a huge system, try to slap on a UI at the end and then protest to the interaction designer that "if we do it the way you are proposing we have to rearchitect everything".

To be honest, I have a lot of sympathy with Cooper's point of view. He, and Norman before him, talks a lot about conceptual models of the system as opposed to the implementation model. The job of the interaction designer is come up with the right conceptual model for the user. That may or may not correspond with the implementation model but, if it does, it makes the job much easier for the programmers. Cooper has a deep-seated fear of the implementation model driving the conceptual model rather than the vice versa. Our job is to help him overcome that fear, but I don't feel that we have the enough of the answers yet. This area is ripe for study.

As I mentioned in a previous post, XP doesn't seem to help me come up with easy to use (as opposed to easy to maintain) UIs. GDD does. A marriage between the two, if such a thing is possible would be a marriage made in heaven. I am experimenting with this on my current project. -- Kevin

I also like the idea that Cooper fulfills the role of the OnsiteCustomer on an XP project, but in a much deeper way. Cooper wants the person who sets the goals for the system to understand the business interactions first, and he does not want engineering considerations to cloud that process. XP does not really prevent an OnsiteCustomer from understanding his business better, but I suppose Cooper would raise these objections to XP:

(I hope I'm not distorting Cooper's position.)

I think Beck admits that XP is more of an engineering methodology than a business processes methodology. This is a weakness and a strength. It is a strength, because different business customers can then use different methodologies for refining their business processes. It is only when they get to talking to the developers that XP really comes into play. XP simply says you must prioritize features quickly and often.

Cooper seems to object more to the "quickly" part than the "often" part. He doesn't want to deliver any requirements to developers until he has completed his entire business process evaluation. This is annoying, but it's probably easy to work around. Kevin suggests system spikes as one idea. I'd be curious to hear other ideas. It seems like an XP team could generate its own stories, such as being able to parse out legacy data file formats.

-- SteveHowell

I was put off a bit with Alan's use of the "designing software is like designing a building" metaphor. I mean, Alan practically invented the tools that let you rapidly build, tear down, and roll back virtual buildings.

Agreed, at one time the cost to refactor a UI was exponential, but XP now thrives on the ability to put a customer and developer in front of a VisualStudio Win Forms designer and rapidly sketch out some functionality. There's very little overhead to move a UI component around or change event handling behavior at a later time. You've misunderstood InteractionDesign if you think it's about moving UI components around or changing event handling behavior. This is an element of UI design, but InteractionDesign is muchly much deeper than that.

Hats off to Alan for being a catalyst for WYSIWYG development and to Kent for capitalizing on RAD tools. What's left to debate between these two?

-- MichaelLeach
I think Alan Cooper's position is interesting, and something that I've tried to nail down for years. The basic problem which Alan highlights is that companies aren't capable of making the decisions necessary to build custom software. This is the essential ArchitectureFollowsOrganization? vs OrganizationFollowsArchitecture? argument. Kent formulated a metholodogy that could live in both worlds, but is best suited to, and geared for, the former. Alan would like for all programmers to stop clacking at the keys until every corporation reaches the latter.

While I agree 100%, in principle, with Alan, I think he's set his hopes way too high. The reality, no matter how bleak, is that a company is just like a person: They carry baggage. When you get into a relationship with a company, just like a person, you have to explore and handle this baggage. Sadly, each case is different. Interestingly, human to human relationships are straining enough in this way, so it's a small miracle that business-entity to business-entity relationships aren't more strained.

I think it's fair to state that XP will be around, in one form or another, for a while. InteractionDesign will probably find its home in very limited circumstances. Such is the way of the programmer. -- JeffPanici

InteractionDesign will probably find its home in very limited circumstances. Such is the way of the programmer. - which is why the inmates will continue to run the asylum...

Cooper is trying to figure out a way of figuring out what to build. XP assumes the customer knows this and can produce the requisite stories in the requisite chunk sizes. XP developers are really not in any position to help with this from a CustomerCentered? POV. It's not just button placement. Cooper to me is correct when he says customers generally don't know what they want. Just assuming they do and making them responsible for this major part of the project is a good deal for developers, but won't give the best results based on customer satisfaction. Customers aren't real happy when you say we didn't what you wanted, but they still don't like it. There's a role for figuring out really what the customer wants/needs. -- AnonymousDonor

Beck is right to be afraid that interaction designers will become a bottleneck. On the other hand, the user goals Cooper talks about are mainly psychological. And it's inconceivable that most users or customers understand the least whit about psychology. And programmers are probably the worst offenders as far as insensitivity to psychological phenomena goes. XP and ID are not irreconcilable. The only substantial difference between them, the question of whether ID and coding should be done in parallel or not, should be settled one way or the other by experiment. -- AnonymousCoward

What is GoalDirectedDesign??

I think this discussion misses the following:
  1. Interaction Design is about designing a program's behaviour in context of the user.
  2. XP is about designing/doing the implementation of this behaviour.

We have the SpartanUserInterface, but that's not designing behaviour. And I have experienced Alan is right in that the customer can't decide what's a good user interface. How many of us haven't been in the discussion "move the button there, change that label..."? I used to take that as a good sign, when it's really a symptom of a user not having a clue of what I am talking about. -- ThomasEyde
The use of InteractionDesign with XP is something I've been wrestling with for a while now. Most people on the Wiki seem very open to the idea which was a pleasant surprise to me. I hope people experiment with it and report on their experiences. -- SteveQuinlan

Case Study about an Interaction Designer working with an eXtreme Programming team

I'd be interested in case studies of Interaction Designers working w/XP coders, but this one doesn't help much. What's described in it ain't Interaction Design. It's really just some rather simple graphic design, fitting a few live data points into a static graphical shell for a gambling-related advertisement. Interaction Design might be designing the management interface that allows customers to buy, manage, and track various advertisement campaigns.
InteractionDesign the techniques I'm way down with. InteractionDesign the "meet the new boss" replacement of one hierarchy with another I think is naive. And Cooper's contention that ID done well eliminates requirements churn is simply snake-oil. We are all of us too good at learning for that to be true. -- KentBeck
Cooper seems to be embracing the Extreme/Agile/Craftsmanship movement: -- SteveQuinlan

View edit of February 26, 2013 or FindPage with title or text search