Mutual Learning approach

1
New Approaches to Design within the context of
CSCW

• Mutual Learning approach
• Collaborative Computing
• eXtreme Programming (XP)

2
Mutual Learning

• Mutual learning replaces traditional systems
  analysis.
• Key points
• Designers must learn more about the domain
• Users must learn about the technological
  possibilities and trends
• Both must learn about co-operative design

3
Co-operative Design - 1
Co-operative design is an instance of
co-operative work. Ideally it involves both
designers and users as well as social
scientists. Users need to be involved so that
their crucial application knowledge is captured.
Often this knowledge is tacit, that is, not
accessible to outside observers nor to
designers/system analysts using conventional
system description methods. But designers by
creating situations where users can trial
computer systems (e.g. prototypes/incremental
development or even mock-ups) may trigger this
knowledge and thus allow it to applied in
development.
4
Co-operative Design - 2
Social scientists/Observers can act as mediators,
help with identification of concepts
Developers abstract datatypes Development/ Const
ruction/ Evolution perspective
Users concrete instances Application/Userperspecti
ve
Application Concepts
Both users and developers need to understand each
others perspectives. The first step towards this
shared understanding is social not technical.
5
Limits to Mutual Learning
Developers/Designers are not in general Domain
Experts. Users in general are not Technical
Experts. Social Scientists in general are
neither Domain Experts, nor technical
Experts. Simple prototypes may be directly
manipulated to reflect better understanding of
users needs, but more complex systems in general
cannot (of course, this is a goal of work on
Domain Specific Languages and End-User
Development).
6
Advantages of Mutual Learning
Combination of diverse sources of
expertise Ownership and Commitment by all the
people who will eventually work on or with the
system Participation in decision-making by the
people who will be affected by design
decisions Early - continual - focus on users and
their tasks Early - continual - testing by
users Iterative design

7
Collaborative Computing
Collaborative Computing emphasises Collaboration
over Computing. Its principal thesis is that
there is no way a system can work well with
people, especially collaborative groups, without
a deep, fundamental understanding of people and
groups. Focusing on technology is inappropriate
where the whole point of technology is to act as
a direct aid to peoples group activities. Such
understanding is crucial because new systems in
the workplace and society have the potential to
change the nature of work and ultimately society.
Changes may be to the pattern of work, of
communication, of knowledge, etc.

8
The Case for People Understanding
1. Systematic, controlled observation is
necessary to achieve an understanding of people
in context. 2. Developers versed in folk
psychology or sociology cannot be a substitute
for professional social scientists. 3. The
principles that apply in the design of software
for individuals are not sufficient for groupware.
Group activity is quite different. 4. Social and
Cognitive Science does not offer ready solutions
for Computer Scientists to apply. Despite some
progress, large gaps in our understanding of
people remain. 5. Lack of people understanding is
not an excuse - failure to address these issues
is bound to lead to system failures. 6.
Artifacts (such as groupware) do not enhance
human abilities they change the task.

9
Normans Key Points
Technology alone cannot provide all the answers
when we are dealing with human activities. Unless
groupware tools fit seamlessly within the
work, cultural and social structure of the users,
they will fail. Computer Scientists cannot
become social scientists overnight, nor should
they. Design teams working on the design of
groupware should include computer scientists,
cognitive and social scientists and
representatives from the user community - all
working in co-operation.

10
eXtreme Programming - XP

• XP experiences distilled (from Paul Dysons
  talk)
• People are key - involve both customers and
  developers.
• Communication between customers and developers is
  crucial.
• Collaboration between customers and developers is
  also crucial.
• Customers and developers have a shared
  responsibility for the system being developed.

11
More recent approaches XP/ASD

• Extreme Programming
• AgileSoftware Development
• ASD considers software development as a
  co-operative game of invention and communication
  involving developers and customers where work
  products of the team should be measured for
  sufficiency with respect to communicating with
  the target group. Alistair Cockburn, Agile
  Software Development, 2002

12
eXtreme Programming - XP

• Key Reference Extreme Programming Explained
  Embrace Change, Kent Beck
• Addison Wesley Publishing Company, 1999.
• This book covers the principles behind XP and its
  potential advantages for small to mid-sized
  software development teams.
• XP relies on the following
• light weight project management,
• getting simplest possible programs working,
• developing unit testing before classes,
• programming in pairs,
• team ownership of code and
• customer involvement during development.

13
What the Chief Exponent has to say

• Principles, such as "rapid feedback" and "play to
  win," form the basis of XP.
• Project managers become coaches and programmers
  work as a team.
• Testing is an intrinsic part of implementation.
• Software development projects can be fun,
  productive and even daring. Yet they can
  consistently deliver value to a business and
  remain under control.
• XP challenges the long-held assumption that the
  cost of changing a piece of software necessarily
  rises dramatically over the course of time.

14
What the Chief Exponent has to say - 2

• Fundamentals of XP include
• Distinguishing between the decisions to be made
  by business interests and those to be made by
  project stakeholders.
• Writing unit tests before programming and keeping
  all of the tests running at all times.
• Integrating and testing the whole system-several
  times a day.
• Producing all software in pairs, two programmers
  at one screen.
• Starting projects with a simple design that
  constantly evolves to add needed flexibility and
  remove unneeded complexity.
• Putting a minimal system into production quickly
  and growing it in whatever directions prove most
  valuable.

15
Why is XP Controversial?

• It doesnt force team members to specialise and
  become analysts, architects, programmers, testers
  and integrators--every XP programmer participates
  in all of these critical activities every day.
• It doesnt conduct complete up-front analysis and
  design. XP projects start with a quick analysis
  of the entire system and XP programmers continue
  to make analysis and design decisions throughout
  development.
• Programmers dont write and maintain
  implementation documentation as communication in
  XPprojects occurs face-to-face, or through
  efficient tests and carefully written code.

16
The XP Lifecycle

• Extreme Analysis - based on development of user
  stories, that is light weight Use Cases. Stories
  are broken down into tasks using Planning Games.
• Extreme Testing - write unit tests before classes
  (compare Microsoft approach).
• Extreme Code - write code to pass tests cases -
  the simplest thing that will work. Pair
  programming - continuous code review and
  integration, e.g. hourly builds.
• Extreme Design - Refactor code, remove duplicate
  code, generally clean-up the code. If more design
  is required use CRC (Class-Responsibilities-Collab
  orators) cards, and group design sessions for
  major problems.
• Extreme Scheduling - customers write stories
  while developers estimate costs. (from Susan
  Eisenbachs BCS talk)

17
Potential Defects of XP

• XP may result in lightweight even skimpy
  documentation. There is reasonable documentation
  on testing, but weak on design.
• The code first, specify/design later may lead to
  sub-optimal solutions.
• The whole approach is inspirational rather than
  systematic and unless you have someone like its
  main proponent, Kent Beck, inspiring your
  developers and customers, it may not work.
• It is questionable whether XP can scale up or is
  appropriate on large projects/safety critical
  projects/applications requiring long term
  maintenance, etc.
• (from Ian Alexanders BCS talk and subsequent
  discussion)

18
References

• Designing for Cooperation Cooperating in Design,
  Morten Kyng, CACM, Dec 1991.
• Collaborative Computing Collaboration First,
  Computing Second, Donald Norman, CACM, Dec 1991.
• Notes from BCS Joint Meeting of Requirements and
  Advanced Programming Specialist Groups, 9 March
  2000 - see also the wiki web on XP which itself
  provides an example of the WWW being used for
  collaboration amongst X Programmers.