Extreme Programming vs. Interaction Design David 22 Aug 2005

15 comments Latest by Anonymous Coward

Kent Beck and Alan Cooper each represent an approach to development and design that aims to create better software. But while there’s overlap, there’s at least as much difference. In an interview with the two luminaries, Cooper believes that designing all the software up front will save us from the cost of programming:

There’s enormous cost in writing code, but the real cost in writing code is that code never dies. If you can think this stuff through before you start pouring the concrete of code, you get significantly better results. You get significantly more efficient programming and you don’t end up with pulled teeth.

Naturally, this doesn’t gel very well with the notion of constant and complete iterations. Partly because it assumes a price on software development that no longer necessarily is true in all domains. Especially web development with modern tools.

And partly because it assumes that the interaction designers “… have the capability of visualizing something as complex as the behavior of software” while the customer does not. It’s our experience that designers, as much as customers, need to see something real in order to produce good designs. Trying to design the whole thing up front is simply too hard and, more importantly, not a beneficial way of developing software.

But while it seems that some Cooper’s assumptions might be eroding, he brings an excellent perspective on the role of design into the traditional XP-idea of a customer-programmer relationship. Just as we’ve said before, programmers alone can not bear the burden of designing software alone.

You definitely need a customer-designer-programmer triangle, but once you have that, it makes a lot of sense to have it play in an XP-like framework of iterations and just-in-time decisions on both features and implementations.

Getting Real is, in large part, an attempt to take Cooper’s notion of design and fit it into XP’s iterations. Design needs to be the bridge between customers and programmers, but it also can benefit from being informed throughout the development. Don’t attempt to fortune-tell it all upfront.

UPDATE: A fellow student from my time at the Copenhagen Business School has actually just recently explored the mix in a paper entilted Introducing User-Centered Design to Extreme Programming (PDF).

15 comments so far (Jump to latest)

RichB 22 Aug 05

Don’t forget that Cooper threw away the codebase for his most famous product and rewrote it - essentially an iteration.

Cooper sold the code which became the basis for Visual Basic to Microsoft. As part of that sale, Cooper negotiated with Microsoft consultancy for rewriting it from scratch.

Mathew Patterson 22 Aug 05

You definitely need a customer-designer-programmer triangle, but once you have that, it makes a lot of sense to having it play in a XP-like framework of iterations and just-in-time decisions on both features and implementations.

I’ve seen better results with this kind of method than one based on designing to a spec document written months ago.

The big reason to get design involved is that business users generally feel a much stronger level of involvement with the user interface than they ever will with the spec or the back end code. That emotional investment can be painful, but it gets much more of the real requirements out in the open.

Anonymous Coward 22 Aug 05

January 15, 2002, come on.

Marko Samastur 22 Aug 05

Personally I prefer to mix different development cultures. It’s good to have something resembling a specification at first, since it makes first stages of development easier and reminds all at least somewhat what we are building.

But after a while, when you gather more experience, you start to learn about what works and what not and after that it’s better to make iterations faster than rewriting spec would. As long as everyone knows when spec stops being a bible and where, there usually aren’t too many problems.

I’m certain though that no approach is good for all scenarios and all people.

Anonymous Coward 22 Aug 05

What has Cooper done in the past 10 years? The dude is coasting.

Dan Boland 22 Aug 05

Sorry to be a pick, but illuminaries isn’t a word; you meant to say luminaries.

But to the point, I agree that it’s way too hard to design anything with any level of complexity up front. In my experiences, most of my good ideas come during the course of writing code as I go along, not during any planning phase.

kingbenny 22 Aug 05

Captain Ridiculous steps in to say, “I think you mean luminaries, not illuminaries.”

kingbenny 22 Aug 05

ha, nice timing - didn’t mean to call you Captain Ridiculous, Dan.

a 22 Aug 05

“What has Cooper done in the past 10 years? The dude is coasting.”

Zing! You know, my first reaction was to defend him. In a small field he really is a giant, and his Inmates Running the Asylum book (probably more than About Face) is really influential.

But you know, you’re right in a way: Cooper seems to have missed out on web-based applications entirely. About Face 2.0 does have a forgettable chapter on the web, but there are (AFAIK) no examples of web work other than the 1998 version of “HP Shopping”. The Cooper Insights newsletter hasn’t been updated in more than a year. And damn are the designs in their portfolio ass-ugly. Purple and green bevelled buttons?

Ryan Platte 22 Aug 05

“It�s good to have something resembling a specification at first, since it makes first stages of development easier and reminds all at least somewhat what we are building.”

XP projects start by having this discussion and creating an initial list of stories. The point of XP is not that you can’t plan anything, but that your plans can change, in big and small ways, and at very low cost.

Holy Cow 22 Aug 05

http://www.joelonsoftware.com/articles/AardvarkSpec.html

rgbiggs 23 Aug 05

I had the debate over documentation and planning in a company that produced reams and reams of paper while the developers were in favor of XP. The bottom line, it turns out, is that documents produce roadmaps, not specifics. And these roadmaps are needed to: 1) maintain the integrity of the user-experience objectives. In other words, there has to be something that continues to keep everyone on the same track about what experience (or behavioral) characteristics you are trying to bring about; 2) generally plot out where the product is headed —- what its trajectory is with respect to business objectives; 3) document decisions as they are made for a whole bunch of reasons, political and practical; and 4) show management that the money it is spending is not to build a product as it is dreamed up in a developer stream of consciousness, but rather as it is targeted with measures of success attached to key features of the roadmap.

Anonymous Coward 23 Aug 05

there has to be something that continues to keep everyone on the same track about what experience (or behavioral) characteristics you are trying to bring about

If these aren’t in the blood of the people working on the project then no words can make it come true.