Ken, and William:

On Monday, October 25, 2004, at 12:27:33 AM, William Pietri wrote:

> On Sun, 2004-10-24 at 21:15, Ken Boucher wrote:
>> I'm sorry, this isn't parsing for me. Are you saying that because
>> you aren't a usability exepert but you are a developer that
>> usability experts can't be developers and developers can't
>> become usability experts?

> Does that matter? Developers can become customers and customers
> developers, but that doesn't mean that we shouldn't keep the roles
> separate.

Long ago, Kent Beck said something that has stuck with me. As I recall it
was in a discussion of why there were only two roles in XP, Customer and
Programmer. He said that he considered the fact that there were even two
roles to be a flaw, but that he could see no way to get rid of it.

Looking over my long coaching history, this is a very high frequency event:

  A team tells me "We're having a problem with X", where X sounds like some
  planning or technical problem. I ask them "Tell me about how you do X".

  They describe how Joe does this part of X and Jane does that part of X.
  They describe some odd interface between Joe and Jane, such as that Joe
  writes things down for Jane to do, or Jane uses Joe's code ... whatever.

  "Have Jane and Joe talk to each other," I say.

(It might even be more frequent than "Do you have a test for that?")

Now then, since you and I both expect problems on the interfaces, we call
our attention to the one "inevitable" interface in XP, the
customer/programmer interface. And we see, quelle surprise, problems. And
we see that the more the developers really understand the domain, the more
smoothly things go, the more the customers really understand what the
programmers are doing, the more smoothly things go. They never go
perfectly, but they go better.

And that, Ken, is what you are saying with one side of your mouth:

> A lot of our programmers have business knowledge and we find that
> knowledge very important. In fact I'd say that teaming programmers with
> no smalltalk experience but lots of domain experience with experienced
> smalltalkers with no domain experience has produced great results.

What I'm saying above predicts that result and suggests that by talking
more to each other, that situation can come about.

But then, Ken, you say:

> If I'm going to do GUI work I need more experience than doing part
> time GUI work is going to provide. I also need to be in a GUI mindset.
> I need to think about things differently. There's a lot of things I
> need to keep in mind when doing GUI work, and if I approach GUI
> work with a model frame of mind I find I'm not thinking about all the
> right things.

And then you suggest a separate GUI team, and then William and I suggest
that there will be problems on that interface. Interestingly, K&W, the two
of you have almost switched sides:

  Ken suggests a split between GUI and Model, and William (and I) recommend
  against it;

  Ken suggests less of a split between Customer (domain) and Programmer,
  and William reminds us to keep the roles separate.

Now I'm suggesting to all of us that perhaps the Whole Team / Sitting
Together notion is at the core of what makes things work well, and that we
all have reason to know it.

Now what shall we do about these GUI persons and model persons?

Ron Jeffries
www.XProgramming.com
I was smarter before I donated my brain to science.
I didn't know they meant NOW.

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
    extremeprogramming-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/