Cooper Vs. Beck

24 Mar 2004 - 4:30am
10 years ago
4 replies
949 reads
Sarah Brodwall
2004

I'm not sure if this article has been discussed here before, but I would
very much like to hear your opinions on
http://www.fawcette.com/interviews/beck_cooper/ (see also
http://c2.com/cgi/wiki?CooperVsBeck).

I'm studying interaction design with a focus on IA, while my husband is an
outspoken proponent of agile software development methods. Probably
because of my husband's influence, I find myself agreeing with a lot of
what Beck has to say here, while Cooper comes off as being somewhat out of
touch with the realities of software development. Have any of you ever
worked as interaction designers on a development team using agile
methodologies? Do any of you come to the field of interaction design from
software development? I'd really like to hear what you have to say about
this article.

--
Sarah Brodwall Time you enjoy wasting is not
sjb at broadpark.no wasted time. ~T. S. Eliot

Comments

24 Mar 2004 - 8:13am
David Clarke
2004

I very much agree with Polya, whose famous book "How to solve it"
separated the solving of problems into four phases:

1) UNDERSTANDING THE PROBLEM
2) DEVISING A PLAN
3) CARRYING OUT THE PLAN
4) LOOKING BACK

Interaction Design implicitly accepts this process, addressing step one
and two, and as Cooper mentioned in his closing remarks: XP comes next,
and addresses step three.

Beck is disagreeing with Polya, whilst Cooper is agreeing. I have to
say I am with Cooper, as I have always agreed with Polya.

David Clarke
University College London
Business Development Manager, Honorary Research Fellow
University College London Interaction Centre (UCLIC)
Mail address: UCL Business, Brook House, 2-16 Torrington Place, London
Office: 020 7 679 6582
Mobile: 07855817731
email: david.clarke at adm.ucl.ac.uk

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Sarah Brodwall
Sent: 24 March 2004 09:31
To: discuss at interactiondesigners.com
Subject: [ID Discuss] Cooper Vs. Beck

I'm not sure if this article has been discussed here before, but I would

very much like to hear your opinions on
http://www.fawcette.com/interviews/beck_cooper/ (see also
http://c2.com/cgi/wiki?CooperVsBeck).

I'm studying interaction design with a focus on IA, while my husband is
an
outspoken proponent of agile software development methods. Probably
because of my husband's influence, I find myself agreeing with a lot of
what Beck has to say here, while Cooper comes off as being somewhat out
of
touch with the realities of software development. Have any of you ever
worked as interaction designers on a development team using agile
methodologies? Do any of you come to the field of interaction design
from
software development? I'd really like to hear what you have to say
about
this article.

--
Sarah Brodwall Time you enjoy wasting is not
sjb at broadpark.no wasted time. ~T. S. Eliot

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements
already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

24 Mar 2004 - 9:37am
Todd Warfel
2003

I think there is value in both cases.

First, Cooper started out as a software developer - that's where his
roots are. During his time as a developer, he felt something was wrong
with the way software was being created - the user was getting left
out. So, he changed his focus to ID and has become a strong, outspoken
advocate ever since.

There needs to be balance between Interaction Design (ID) and Software
Engineering (SE). Beck states that one could spend a lot of time trying
to define requirements and blah, blah, blah, or just get into it and
ask the customer (or help them) to break that one bullet point into
twelve. Isn't that creating requirements? Might not be the 30-60pp
document we're used to, but 12 bullet points can also be better and
something that both ID and SE can deal with. I can't tell you the
number of engineers we've dealt with that would rather have one page
than 30 to get lost in.

Both are talking about changing the organization, just taking different
models, slightly. They both want to get the customer more involved.
However, for Beck that customer is the guy paying the bill. For Cooper,
it's the guy paying the bill and the one using the software - two
different people.

I think Cooper understands the SE environment better than Beck
understands interaction design. That becomes even more evident when
Beck proposes a product development with 60 people - each one gets 30
to direct. Then he gives Cooper 1 week to tell the development team
what they want to see. Yet, he doesn't give his development the same
constraint - 1 week to develop the product. This shows that Beck sees
ID as an after thought, and expense rather than a requirement in the
whole process. That's a very dangerous outlook that leads to failed
products - we've seen it dozens of times in the past. And every time,
the product comes out with all kinds of inconsistencies, the customer's
complain, the company incurs additional expense to rework the product,
for support, for training on the product. This could have been avoided
had the work been done upfront instead of after it's "built."

Now, I don't agree with Beck's interpretation of Cooper stating that
"all the design work needs to be done before writing a line of code." I
don't think that's Cooper's philosophy, but then again, Cooper never
argued against that interpretation. Either way, I don't think that's
the right approach. Our DIVE© processes recognizes that
design/development is a phased and overlapping approach and we
accommodate for that. So, in our interaction models, we try and
identify core, reusable components. The advantage with our approach is
that this allows a design team to break up interactions and distribute
them across the team. Then once those core interactions are designed
(e.g. registration component, shopping cart component, shopping list
component) they can be handed off to the development team. The
development team can start the framework and build these core, reusable
components. It's akin to constructing the foundation and framing the
house prior to putting the windows, walls, and wiring in.

They can get started, bite off a small amount, get a feeling for where
we're going, and get to work. This makes everyone happy and gets the
project underway.

Guess for me, they both have valid points, but Cooper errors more on
the side of reality, where as Beck errors more on the side of theory.
And you know where I stand on that one!

On Mar 24, 2004, at 4:30 AM, Sarah Brodwall wrote:

> I'm studying interaction design with a focus on IA, while my husband
> is an outspoken proponent of agile software development methods.
> Probably because of my husband's influence, I find myself agreeing
> with a lot of what Beck has to say here, while Cooper comes off as
> being somewhat out of touch with the realities of software
> development.

Cheers!

Todd R. Warfel
User Experience Architect
MessageFirst | making products easier to use
--------------------------------------
Contact Info
voice: (607) 339-9640
email: twarfel at messagefirst.com
web: www.messagefirst.com
aim: twarfel at mac.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

24 Mar 2004 - 11:04am
Alain D. M. G. ...
2003

Hello!

Looks like two software engineers arguing amongst themselves. Cooper
likes to put on an ID hat but when I look at all those structures he
advocates he is really a software engineer deep down. Beck has some
alluring iterative design there, but no provision for ethnographic work
within it.

The only successful projects I have known all used some form of fast
iterative design getting concrete user testing and reaction in the loop
as early as possible, and then repeating things within a larger,
flexible management framework. Both Cooper and Beck have traits which
could support this, both have traits which could wreck it.

Alain V.

--- Sarah Brodwall <sjb at broadpark.no> a écrit : > I'm not sure if this
article has been discussed here before, but I
> would
> very much like to hear your opinions on
> http://www.fawcette.com/interviews/beck_cooper/ (see also
> http://c2.com/cgi/wiki?CooperVsBeck).
>

__________________________________________________________
Lèche-vitrine ou lèche-écran ?
magasinage.yahoo.ca

24 Mar 2004 - 2:30pm
John Vaughan - ...
2004

Coding and Interaction Design are two opposite (tho - hopefully -
complementary) perspectives on the same task. Coding is machine-centric and
inside/out; Interaction Design is customer-centric and outside/in. It's
always been an interesting, dynamic debate. I have coding skills since the
80's, but don't consider it to be a job description for me now. I
consciously opted out of that arena when I realized that dynamism =
schizophrenia when you try to do it all. It is difficult - if not
impossible - to wear both hats effectively.

The challenge is for these two radically different mindsets to play together
gracefully. Conventional IT teams tend to be coder-centric, both in terms of
philosopy and staffing. Documentation, Process and Design (in the sense of
Interaction Design and Usability) are rarely well-represented. The
Cooper/Beck debate hinges on "territoriality creep". The Interaction Design
discipline is neither well-represented nor well-integrated nor
well-protected in the conventional IT environment. In that situation,
qualitative issues (i.e. Usability) become a political football.

In such a game Interaction Design is already at a profound disadvantage:
Size of team, boundaries, homefield advantage, leadership, scoring system,
resources, time of play, rules & enforcement all lie with the coders. Now
it seems that Beck won't even let us have the ball first.

Simplistic thoughts:

Extreme Programming is
* a reflexive response to the emerging credibility of Interaction Design as
a discipline
* fueled by the threat of downsizing/outsourcing from the beancounters
* an expression of the universal desire to be an artist

John Vaughan
email: vaughan1 at optonline.net
website: http://www.jcvtcs.com
Voice: (973) 316-1182
Fax: (973) 316-1183

----- Original Message -----
From: "Todd R.Warfel" <lists at mk27.com>
To: "Interaction Designers" <discuss at interactiondesigners.com>
Sent: Wednesday, March 24, 2004 9:37 AM
Subject: Re: [ID Discuss] Cooper Vs. Beck

I think there is value in both cases.

First, Cooper started out as a software developer - that's where his
roots are. During his time as a developer, he felt something was wrong
with the way software was being created - the user was getting left
out. So, he changed his focus to ID and has become a strong, outspoken
advocate ever since.

There needs to be balance between Interaction Design (ID) and Software
Engineering (SE). Beck states that one could spend a lot of time trying
to define requirements and blah, blah, blah, or just get into it and
ask the customer (or help them) to break that one bullet point into
twelve. Isn't that creating requirements? Might not be the 30-60pp
document we're used to, but 12 bullet points can also be better and
something that both ID and SE can deal with. I can't tell you the
number of engineers we've dealt with that would rather have one page
than 30 to get lost in.

Both are talking about changing the organization, just taking different
models, slightly. They both want to get the customer more involved.
However, for Beck that customer is the guy paying the bill. For Cooper,
it's the guy paying the bill and the one using the software - two
different people.

I think Cooper understands the SE environment better than Beck
understands interaction design. That becomes even more evident when
Beck proposes a product development with 60 people - each one gets 30
to direct. Then he gives Cooper 1 week to tell the development team
what they want to see. Yet, he doesn't give his development the same
constraint - 1 week to develop the product. This shows that Beck sees
ID as an after thought, and expense rather than a requirement in the
whole process. That's a very dangerous outlook that leads to failed
products - we've seen it dozens of times in the past. And every time,
the product comes out with all kinds of inconsistencies, the customer's
complain, the company incurs additional expense to rework the product,
for support, for training on the product. This could have been avoided
had the work been done upfront instead of after it's "built."

Now, I don't agree with Beck's interpretation of Cooper stating that
"all the design work needs to be done before writing a line of code." I
don't think that's Cooper's philosophy, but then again, Cooper never
argued against that interpretation. Either way, I don't think that's
the right approach. Our DIVE© processes recognizes that
design/development is a phased and overlapping approach and we
accommodate for that. So, in our interaction models, we try and
identify core, reusable components. The advantage with our approach is
that this allows a design team to break up interactions and distribute
them across the team. Then once those core interactions are designed
(e.g. registration component, shopping cart component, shopping list
component) they can be handed off to the development team. The
development team can start the framework and build these core, reusable
components. It's akin to constructing the foundation and framing the
house prior to putting the windows, walls, and wiring in.

They can get started, bite off a small amount, get a feeling for where
we're going, and get to work. This makes everyone happy and gets the
project underway.

Guess for me, they both have valid points, but Cooper errors more on
the side of reality, where as Beck errors more on the side of theory.
And you know where I stand on that one!

On Mar 24, 2004, at 4:30 AM, Sarah Brodwall wrote:

> I'm studying interaction design with a focus on IA, while my husband
> is an outspoken proponent of agile software development methods.
> Probably because of my husband's influence, I find myself agreeing
> with a lot of what Beck has to say here, while Cooper comes off as
> being somewhat out of touch with the realities of software
> development.

Cheers!

Todd R. Warfel
User Experience Architect
MessageFirst | making products easier to use
--------------------------------------
Contact Info
voice: (607) 339-9640
email: twarfel at messagefirst.com
web: www.messagefirst.com
aim: twarfel at mac.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

Syndicate content Get the feed