Classically, design-intensive approaches have at least paid lip service to the idea that users--to the extent it was feasible to inject them into the design process--could improve the outcome. Cooper flatly rejects that notion. Designing complex systems is hard, he said; only minds that are innately talented, and then specially trained, can do it well. Users can't articulate what they need, and may not even recognize it when they see it.
There was a fascinating contradiction in Cooper's talk. His arrogant-sounding assertion that users wouldn't know what they wanted, even if they saw it, was offset by a deeply humanistic take on the failure of product planning and design. The problem here, he said, is that the "happy fraternity" of business, engineering, and marketing managers has been torn asunder.
Whilst we'll agree with Cooper that often users can't fully articulate what they want or what they're doing (there is often a gap between their actual behaviour and their opinion of their own behaviour), he must recognise [must... read... Inmates book again] that to a certain extent customers *must* know what they're doing, otherwise they would not have, in the first place, articulated the business requirement that led to the product/design requirement.
Cooper (ID) takes the view something like: if we design this right, the product will succeed; XP (and we assume Udell is a fan) takes a view more like: let's get started, and in a manner that's flexible enough that we can change it if we need to. This takes us back to Jan 2002, when Kent Beck (XP) and Alan Cooper (interaction design) went to head to head.
Cooper: 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. [...] XP says, "OK, so, I can't change the organizational failings, so, I'm going to build my own internal defenses." I suppose this is probably better than nothing, but I'm interested in changing the way organizations are constructed. I believe that in order to create quality software, you have to change the organization. We can change the organization, and it strikes me that the assumption underlying XP is that the organization's structure is a given.At which point they start disagreeing on whether the practices XP uses are genuine changes to the organisation or not. And we get onto whether project change is inevitable (interesting skyscraper metaphor used here by Beck to make a good point that while in the real world you wouldn't decide to jack up your building so you could add 50 new stories, in the software world it's daily business), and whether, even if it were inevitable, change needs to be expensive (Cooper: "programming is so hellishly expensive"; Beck: "I'm going to give you a process where programming doesn't hurt like that") . Some way on, in discussing phasing, we return to the metaphor of architecture and buildings being an engineering practice that software engineering should aim for.
In the end, they've found some common ground, but also some fundamental differences, which Cooper summarises:
XP assumes the people you're working with are going to jerk your chain, so you embrace that and work with it. And I actually think XP is a pretty good methodology for dealing with that. I'm saying, "Let's go to the root of the problem, which is the people who run our companies and jerk our chains back and forth, because they don't understand software." You can't teach them to understand software.
So... both worldviews assume that there is a fundamental organisational/human disfunctionality at work in the busines-of-creating-software: On the one hand XP is pragmatic and process-centred: it assumes the disfunctionality is embedded in the process (clients will change their minds etc), and orients its practices around making the software process adaptable and flexible - so that the cost of (nearly inevitable) change is lower. On the other hand, ID takes a design- and goal-centric view: it assumes that the disfunctionality resides in users and customers *a priori*: they don't know what they want; furthermore that project change should not be inevitable, it should be avoided. ID's practices then are oriented around fixing the vision of the users' goals, the resultant product. Designing it right the first time.
Which is easier to implement in the trenches? Even though XP has some some practices that raise corporate eyebrows (pair-programming etc), you have to wonder whether this is easier than re-educating customers so that they'll recognise that you're the designer and they have to sit back now and wait. Is it easier to start making progress with XP, or do both methods require an all-or-nothing commitment? Ultimately, as Antimega comments, "It's just a pity they're fighting in different rings".
[via antimega and others]
Related: Steve McConnell's Contrux looks at XP (PDF file)