Cooper on Cooper vs Beck

A really useful piece from IxDA on the Beck (XP) vs Cooper (agile) of the discussion that was requested in a post. The most interesting post was from Cooper himself, who stressed how the discussion is no longer relevant with the changes that agile has come through both with the development of interaction design and agile community.

What I find really interesting is the point:

"Agile is a significant and positive movement in the world of technology, just as the movement for design has been. They are NOT AT ALL MUTUALLY EXCLUSIVE and I'm actively working with a broad range of agilistas to find effective common ground."

This is where my research research also lies in finding this common ground.

And although Cooper says

"Please don't listen to this recording.It was made a long time ago and it is NOT representative of anybody's current thinking."

From a research perspective, I think this helps to highlight the changing and evolving process of agile and so helps to emphasize the demands placed upon interaction design to mange and cope with finding and understanding where the common ground lies.

Cue a methodology...

For the full IxDA Cooper vs Beck post
http://gamma.ixda.org/discuss.php?post=41166

Alan Cooper

Sunday 9:29pm

Apurv,

Please don't listen to this recording.

It was made a long time ago and it is NOT representative of anybody's current thinking.

At the time, Kent Beck was pushing pure XP, which is decidedly NOT the same thing as what is currently known as "agile". My opinions about XP are NOT the same as my opinions about agile. In the years since that recording was made, much has been learned by both the interaction design community AND by the agile community about what the world of software needs and how our two practitioner communities can provide it.

Kent's innovations such as pair programming and test driven development are powerful and effective tools. When they are paired with the agile concept that I call "responsible craftsmanship", the synergy is fantastic. While Kent and I still have significant points of departure in our thinking, I'd wager that he would not take the same stance today that he did in 2004, and I know that I don't (would you?) . Over a year ago I asked Kent to record our "debate" anew, and while he was game for doing it, the logistics never came together.

Agile is a significant and positive movement in the world of technology, just as the movement for design has been. They are NOT AT ALL MUTUALLY EXCLUSIVE and I'm actively working with a broad range of agilistas to find effective common ground.

Please don't dredge up old arguments and mis-apply them to new ideas.

Thanx,
Alan
cooper | Product Design for a Digital World
Alan Cooper
alan at cooper.com | www.cooper.com
All information in this message is proprietary & confidential. "Whenever you are asked if you can do a job, tell 'em, 'Certainly, I can!' Then get busy and find out how to do it." - Theodore Roosevelt

Original Message
From: discuss-bounces at lists.interactiondesigners.com [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Apurv Sent: Thursday, April 09, 2009 5:35 PM
To: discuss at ixda.org
Subject: [IxDA Discuss] Content of Cooper vs Beck

Hi all,

While looking interaction design in an agile context, I'm constantly coming across a certain very landmark public discussion from 2004 between Alan Cooper and Kent Beck (of Extreme Programming) mentioned across the web. It seems this was a very insightful discussion and I am very curious to read it.

The original link to the content however is dead - http://www.fawcette.com/interviews/beck_cooper/default.asp

Would anybody have a copy of it stored with them and be able to share it with me? I'd be humongously grateful!

Here's the link to the Cooper vs Bech discussion on IXCD years ago - http://www.ixda.org/discuss.php?post=1079

Cheers,
Apurv

Some useful process related notes

Konigi - process Notebook

Schedule and Cost Summary Calculator Template

How Software is Built: Interview with Liz Danzico

The Language We Use

20 Steps to Better Wireframing

Is Good Design Replicable?

Designing by Writing

User Centered Design Work Process Toolkit

Doing Sketch Iterations

Software Tool Design: Design by Sketching

How do you design? Ebook

What Goes into a Well-Done Critique

Cockburn's Basic Use Case Template

The what, when and why of wireframes

Bill Buxton Lecture on Sketching and Experience Design at Stanford

Problem Analysis is Not the Key to Successful Design Process

Small Design Teams Are Better

Questions for IA/IM vendors

nForm UX Trading Cards

Denning and Yaholkovsky on Real Collaboration

The Fine Art of Wireframes

Design Eye for South By

Apple's Design process

10 Ways To Get Design Approval

The role of software design

A useful quote to draw on for how the act of a designer for software should
be perceived - is this where the role of the interaction designer defines itself to exist within?

"Software design is the act of determining the user's experience with a piece of software. It has nothing to do with how the code works inside, or how big or small the code is. The designer's task is to specify completely and unambiguously the user's whole experience"

. -- DavidLiddle, From Bringing Design to Software, edited by Terry Winograd, 1996

What is Systems Design?

An useful definition to be aware of for my own process and the overlap that software developers have found themselves in. The lack of clarity that has gone before and continues to go on in the understanding of the system design I feel is connected to the thoughts of Alan Cooper and the goal directed design process. (More thoughts on Goal directed design documented in the next post)

The following text is the pre-edited version of an interview of Hugh Dubberly by Dan Saffer. The interview was performed via email in February of 2006, and was later published in Designing for Interaction: Creating Smart Applications and Clever Devices.

What is system design?

Systems design is simply the design of systems. It implies a systematic and rigorous approach to design—an approach demanded by the scale and complexity of many systems problems.

Where did it come from?

Systems design first appeared shortly before World War II as engineers grappled with complex communications and control problems. They formalized their work in the new disciplines of information theory, operations research, and cybernetics. In the 1960s, members of the design methods movement (especially Horst Rittel and others at Ulm and Berkeley) transferred this knowledge to the design world.

(This can be used in the background in the literature review)

Systems design continues to flourish at schools interested in design planning and within the world of computer science. Among its most important legacies is a research field known as design rationale, which concerns systems for making and documenting design decisions.

What can designers learn from system design?

Today, ideas from design methods and systems design may be more relevant to designers than ever before—as more and more designers collaborate on designing software and complex information spaces. Frameworks suggested by systems design are especially useful in modeling interaction and conversation. They are also useful in modeling the design process itself.

This is significant to the IEAT process in order to ask and further test my own ideas against how system design communicates the information in the design process?

What is the most important thing to be aware of in system design

A system design approach asks

For this situation, what is the system?

• What is the environment?
• What goal does the system have in relation to its environment?
• What is the feedback loop by which the system corrects its actions?
• How does the system measure whether it has achieved its goal?
• Who defines the system, environment, goal, etc.—and monitors it?
• What resources does the system have for maintaining the relationship it desires?
• Are its resources sufficient to meet its purpose?

A initial comparison draw from this and applied to the IEAT process?

A systems approach to design asks: - to help provide questions/perspective for a developer ?

• For this situation, what is the information ecology?
• What is the ecology?
• this asks what goal does the system have in relation to its information ecology?
• What is the feedback loop by which the system corrects its actions?
• How does the system measure whether it has achieved its goal?
• Who defines the system, environment, goal, etc.—and monitors it?
• What resources does the system have for maintaining the relationship it desires?
• Are its resources sufficient to meet its purpose?

Is system design incompatible with the user centered design approach?

A systems approach to design is entirely compatible with a user-centered approach. Indeed, the core of both approaches is understanding user goals. A systems approach looks at users in relation to a context and in terms of their interaction with devices, with each other, and with themselves.

What is the relationship between system design and Cybernetics?

Cybernetics (the science of feedback) provides an approach to systems and a set of frameworks and tools. Among the most important ideas for designers:

• Definition of a system depends on point of view (subjectivity)
• We are responsible for our actions (ethical stance)
• All interaction is a form of conversation
• All conversation involves goals, understandings, and agreements

Are there times when a system design approach is inappropriate?

A systems approach to design is most appropriate for projects involving large systems or systems of systems. Such projects typically involve many people, from many disciplines, working together over an extended period of time. They need tools to cope with their project’s complexity: to define goals, facilitate communications, and manage processes. Solo designers working on small projects may find the same tools a bit cumbersome for their needs.

- A difference noted here is that system design deals with 'projects involving large
systems or systems of systems.' With the information ecology the purpose is to reduce down the complexities and have the focus upon the information movement within the ecology.

Will the IEAT process required similar identification to say when and when not it is
appropriate for the perspective of selling the idea to a software developer, interaction designer?