Extreme Programming vs. Interaction Design

Extreme Programming vs. Interaction Design


Elden Nelson interviews Kent Beck, the founder of the Extreme Programming method and author of “Extreme Programming Explained: Embrace Change”; and Alan Cooper, the prime proponent of interaction design and author of “The Inmates are Running the Asylum”. The interview is well worth the effort of navigation through the horrible interaction design of FTPOnline.


Beck’s analysis of interaction design and “Inmates” expresses exactly how I felt about the book when I read it: Interaction design has a lot of really powerful tools to really important questions. However, it constraints itself to working with software people because of assumptions that simply are not true anymore. I share Beck’s opinion that both disciplines have a lot to teach each other.


There is one thing I wished Beck had responded differently on, however:



Beck: […] 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.


No, embracing changing requirements is not an abdication. It is a realisation that the most valueable insights into systems come after those systems have been put into production. Changing requirements is a sign of a product that the users use it, care about it, and gets value out of it. By resticting interaction design to the inception of the product, Cooper limits the impact it could have on real systems. I would like to juxtaposition Cooper’s statements in the interview with Robert Glass’ Facts 43 and 45 from “Facts and Fallacies of Software Engineering”:



Fact 43: Maintenance is a solution, not a problem.


Fact 45: Better methods lead to MORE maintenance, not less.


Now read the interview.

Copyright © 2004 Johannes Brodwall. All Rights Reserved.

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in Software Development. Bookmark the permalink.

Comments are closed.