extreme programming vs. interaction design?
May 05, 2008
In January 2002, Elden Nelson wrote “Extreme Programming vs. Interaction Design: When two development design visionaries meet, there’s room for consensus–but not much (via The Sticky Bit and the Internet Archive). This fabulous interview with Kent Beck and Alan Cooper contrasts two modern methodologies for getting software right. These challenging questions are no less relevant six years later. I believe that we should take guidance from both philosophies, and that they are not mutually exclusive.
Alan is absolutely right that there needs to be up front design. He talks about designing human behaviors before you even consider defining an interface, thinking about what buttons go on the screen. He notes that interaction design focuses on the behavior of complex systems, of humans and of organizations. He comments: “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.” In my experience, sometimes we can fix the organization and sometimes we can’t. Usually we can just nudge it in the right direction, but some of the age old problems will exist. It’s easy for a management team to just remove design from the process in the name of XP.
Alan would keep engineers away from customers, fearing that engineers lack insight into human processes and will merely “automate the pain.” He draws an analogy with an architect and a builder; however, I believe architects study construction and the engineering principles behind building a lot more than most interaction designers study the technology they work with. After much discussion, Alan agrees that needs to be a back-and-froth and that engineers need to be involved with the design.
The major contention in this article seems to be about whether the engineers start work day 1 or day X, but afterwards both believer they should work together. I’d like to see a project with Alan and Kent both on board where Alan’s team was doing interaction design while Kent’s team was writing stories. I love Kent’s ideal of writing code that is flexible and becomes more resilient over time not less, but it is clear that Alan just doesn’t believe it, and I agree that ideal is pretty tough to achieve.
Here are some quotes from the interview which I enjoyed….
Cooper: It’s my experience that neither users nor customers can articulate what it is they want, nor can they evaluate it when they see it.
Kent Beck:
One of my goals in XP was creating teams that even in highly constrained and emotionally charged business environments could produce programs that didn’t lose their ability over time but, in fact, gained capacity over time. As components are factored out, as configurations emerge from the customer team–which you might call the interaction team–the program is still getting better and better in five years. The team gets the attitude where they go back to the customers and say, “You’re giving us easy stuff. Give us a hard one.” The customer team is actually challenged, over time, to think bigger and bigger thoughts as development goes on.
And here’s my favorite exchange, following where Alan Cooper was talking about how the right design up front keeps the requirements from shifting, since you get them right upfront (which I don’t know if I agree with, I suppose it depends on the length of the development cycle):
Beck: Yeah, but I would say exactly the opposite. For all its Dilbertesque qualities–and I’m still proud of having said “Embrace Change” in the title of the first XP book. I’ve consciously decided to give up the ability to predict the future.
Cooper: I see that in XP. It’s an abdication.
Beck: Is Zen an abdication?