Search:

eriksmartt.com/blog

 

Topics:

  • arduino (3)
  • art (2)
  • austin (39)
  • automotive (15)
  • blogging (25)
  • books (14)
  • business (5)
  • code (15)
  • design (10)
  • diy (3)
  • django (9)
  • experience (17)
  • family (2)
  • film (4)
  • food (1)
  • for:optaros (2)
  • gadgets (11)
  • games (11)
  • garden (3)
  • green (5)
  • hack (13)
  • hardware (11)
  • hci (9)
  • life (13)
  • lifehack (11)
  • links (71)
  • linux (8)
  • living (3)
  • make (3)
  • media (7)
  • mobile (98)
  • music (2)
  • news (17)
  • osx (29)
  • outdoors (4)
  • privacy (2)
  • product-management (1)
  • python (75)
  • quote (3)
  • security (10)
  • society (21)
  • software (38)
  • spam (2)
  • syndication (5)
  • technical (31)
  • technolust (5)
  • transportation (12)
  • travel (25)
  • ubuntu (7)
  • web (67)
  •  

    “Extreme Programming vs. Interaction Design”

    Filed under: design, hci, technical — August 23, 2005

    Here’s a topic that hits rather close to home: In the interview, “Extreme Programming vs. Interaction Design“, Kent Beck and Alan Cooper discuss opposing views on producing better software, and unfortunately, I can’t say that either one really “wins” the argument.

    The piece hits close to home because I used to work in Interaction and Information design, so I fully grok the value proposition Cooper presents. The argument is the typical Human-Computer Interaction (HCI) / User-Centered Design (UCD) pitch — that up-front interaction design will (1) produce a higher-quality product, and (2) will reduce development costs by solidifying technical requirements. However, what surprised me in the interview is that Cooper seems inflexible on how to best apply this UCD process, insisting that it is a design “phase” that starts and finishes before any development begins.

    The central assumption in Cooper’s argument is that programming is expensive and programmers are unwilling to throw out prototype code. Because of this, Cooper believes that you should not allow programmers to begin working on a project until 100% of the requirements are set. I used to believe that too, but I have since seen the light.

    The trouble is, rigid processes with pre-defined phases and deliverables are best used when managing a large group of low-to-moderately skilled developers. However, small teams of smart people change the rules and the outcome. Development teams that recognize the value in Agile Development and XP also understand that the assumptions driving waterfall-style development phases are based on faulty assumptions, which easily fall apart given the following findings: (1) It *is* possible to reduce the cost of developing code (see Python and Ruby on Rails); (2) Better products are often the result of iterative design (compare a forth-gen iPod to a first-gen); and (3) If your programmers aren’t capable of “sketching in code”, you need to hire better programmers (see all of Paul Graham’s and Joel Spolsky’s articles ;-)

    This isn’t to say that interaction design isn’t helpful, because it most certainly is, and any company serious about serving it’s customers should at least consult a user experience and interaction designer about their products, if not have such a designer on the team; However, there is even greater value in rapid iterative development — both in interaction and implementation, and companies that understand how to utilize this advantage will produce higher-quality user experiences in a shorter time-to-market.

    (via Signal vs. Noise.)



    Leave a Reply


     

    A few books I'm reading now:

    A few books I'd recommend: