KentBeckFacesOff

This URL http://www.fawcette.com/interviews/beck_cooper/ was originally posted under XpInTheNews

First off, the statement by Kent that: you can build a program that improves with age instead of having it born powerful and gradually degrading until you just think, "Oh, this is crap and we have to start over." really struck a chord. I am currently adding small bits of functionality to a large system that was written to a large spec, and which - with the best will in the world on my part - is entropying with each modification. Not to mention the fact that it was written for a very specific runtime environment that is soon going to change, which will no doubt cause further degradation of the codebase... until some one comes in and starts over again. What a contrast to the XP team on a roll who know their product keeps getting better with each iteration!

Also: 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. Essentially, the crap rolls downhill and ends up rolling right into the programmer's lap. Did anyone else recognise this assumption as being essentially true in their non-Xp experience? XP's big win (IMO) is the way that it formalises the way the crap rolls downhill (to coin a phrase), through the rules and the roles of the players on the project (manager, customer, team). This makes it harder to play the dysfunctional blame game, and easier to behave as adults and negotiate win-win solutions.

Beck believes XP is the answer because this way the customers have complete control over what goes in the product and therefore get what they want.

Cooper believes that customers don't necessarily know what they want and that typical customers will simply try to automate the tasks they presently do. However, by taking a step back and looking at the bigger picture (which XP tends not to encourage) and looking at end goals with an experienced 'interaction designer' they could come up with a superior solution which the customers would not have come up with on their own.

DavidPeterson

My gripe with Cooper's comments is that he seems to be saying that interaction designers are not programmers and programmers are not interaction designers. Specialisms have their role in every project, but specialists do not! IMO the best XP teams work by having talented individuals able to wear many hats: e.g. architect, coder, tester, maintainer, conscience, clown, motivator, ... and yes, application or UI (or interaction) designer. By pairing with people who have different specialisms - or to put it another way, have had different experience - our professional knowledge increases and the customer gains.

As an aside, I also find Beck's comments more palatable than Cooper's because he starts from the position of respect for the customer. Not 'stupid customer, doesn't know what they want, they need an interaction designer....' but 'here we are in a team together, we'll solve this problem of the system / UI design, iteratively and jointly...' Being a programmer in an XP team does not mean abdicating all responsibility for everything to the customer!

TimBacon

This paper, http://www.foruse.com/Files/Papers/agiledesign.pdf (pages 4-7), by Larry Constantine puts forward similar ideas to Cooper, that there are strong advantages to nailing down the user-interactions (and hence the user-interface) as early as possible:

When it comes to the user interface, later refinement of the architecture is not an acceptable option because it means changing the system for users who have already learned or mastered an earlier interface. Even small adjustments in the placement or form of features can be problematic for users. Whereas refactoring of internal component structure need not necessarily have any manifestations on the user interface, redesigning the user interface architecture is unavoidably disruptive for users.

DavidPeterson

:-) I have a printout from one of Constantine's slides up on in my cubicle: To users the users interface IS the system. UI design is not an afterthought. Couldn't agree more (but I still don't think it takes a dedicated specialist interaction designer to do this...!) -- TimBacon