Cooper Vs Beck

http://web.archive.org/web/20030208013052/http://www.fawcette.com/interviews/beck_cooper/ 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.

Much of Cooper's thinking seems to be predicated on the notion that software gets worse over time. XP stands firmly against that, but Cooper keeps talking about changing software as "scabby". Either he doesn't understand the organizational implications of XP, or he thinks it's bullshit and is too polite to say so. Regardless, if you genuinely believe that software is an inherently brittle medium -- his comparison to building a bridge is revealing, I think -- then, yes, you're a lot more likely to go for the BigDesignUpFront that he seems to advocate.
Cooper loses points when he balks on Beck's challenge to give him requirements in one week.This also seems to stem from a fundamental misunderstanding of how this stuff works on a technical level. You don't need to work out interaction design to get very basic specs. You can work on the general behavior later; but you can throw in some essential functionality while you're doing it. When your code is well-factored enough, grafting behavior onto the model is easy. And if it's difficult, hey, you just refactor and suddenly it's easy again!
Cooper assumes too much pessimism on the part of XP. He says that XP's belief in changing requirements is because programmers get people always "jerking their chain". Maybe I'm an idealist, but I think of it this way: Software requirements change all the time because software is really complicated. And it doesn't matter how smart and sincere your customers are. If they're not software specialists - usually they aren't - it's asking too much to ask them to get it all right the first time.
On the other hand, I think Cooper is far too optimistic about the average software project. Many (if not most) software projects are doomed to failure because they get mired down in excessive production cost, or excessive slipped schedules. Yes, good InteractionDesign is fairly important, and this is why Cooper has a job. But if every software shop in the world could only adopt ExtremeProgramming or InteractionDesign, more projects would be pulled from the jaws of death by the former.

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

ExtremeProgramming puts a lot of emphasis on evolutionary design. Evolving this stuff on the programmer side seems easy, because you can keep the numbers down, and decrease the pressures on ConceptualIntegrity. But if you're dealing with a software product with a large enough user base, I don't know that you can simply evolve a set of behaviors/metaphors/interactions that makes the most sense for all of them. It seems like the kind of challenge that might require significant up-front analytical investment like Cooper recommends.
- If there are conflicting segments in the user-base, then you either evolve a minmax compromise (perhaps getting stuck in a local minimum) or you would eventually get different software for each. In evolutionary terms, you either get a generalist, or the niches are different enough and you get speciation. -- MichaelBernstein
ExtremeProgramming assumes that you'll find TheMythicalXpCustomer, but does not go into much detail about how to find or build that customer. In practice it seems quite difficult, for many non-technical reasons. It seems to me that ExtremeProgramming might gain some ground if it more explicitly limited its scope; if its advocates said "This is the best way to get the code you want, but it doesn't tell you how to figure out what code you want." (There's more on this at XpDoesntCoverThat.)

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..

Identify personas
Identify goals (as opposed to tasks)

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

Enumerate scenarios

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:

XP doesn't really give tools for understanding business interactions.
XP rushes the customer into coming up with features before he's ready.
XP forces the customer to prioritize tasks that require less engineering effort, instead of focusing on important business interactions.

(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??

see http://www.cooper.com/articles/art_goal_directed_design.htm

I think this discussion misses the following:

Interaction Design is about designing a program's behaviour in context of the user.
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 http://www.id-book.com/casestudy_xp.htm

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: http://www.fawcette.com/vsm/2002_12/online/the/ -- SteveQuinlan

CategoryComparisons