Extreme Programming discussions

Onward!
Seeking New Paradigms & New Thinking

Chair: Richard P. Gabriel, Sun Microsystems
onwa…@oopsla.acm.org

Overview

The OOPSLA 2003 Onward!  Track welcomes papers describing new paradigms and
metaphors in computing, new thinking about objects, new framings of
computational problems and systems, and new technologies.  Onward!  papers
need not advance the state of the art, but should aim, instead, to alter or
redefine the art by proposing a leap forward-or sideways-regarding
computing.  Papers in the following areas are welcome, as are any papers
representing radical thinking of interest to theoreticians and
practitioners at OOPSLA:

    * programming language theory, practice, and design
    * architectures
    * software development
    * methodologies
    * environments
    * education
    * ethics
    * paradigms, metaphors, philosophy, and problem framings

An Onward!  paper need not contain a fully worked out theory or implemented
system, but must be well-thought-out, well-written, and compelling in its
vision or uniqueness of thinking.  Papers submitted to Onward!  will be
reviewed by a separate program committee, and in some cases papers
submitted to the regular Technical Program may be directed to Onward!.
Accepted papers will be presented in parallel with the OOPSLA regular
technical program and published in an ACM publication.  There is no page
limit for submitted papers, but there may be reasonable publication limits.
Onward!  will have a Keynote speaker during an evening session open to the
general public.

The Onward!  Track is separate from the regular OOPSLA technical
program-regular technical papers should be submitted to the OOPSLA
Technical Program.  Onward!  papers will not appear in the OOPSLA
Proceedings nor will papers be subject to the same rules of the Technical
Program review process.

Important Dates

Firm deadline for receipt of submissions: March 21, 2003
Notification of acceptance or rejection: tbd
Deadline for camera-ready copy: tbd

For More Information

For additional information, clarification, or answers to questions, please
contact the Onward!  Chair, Richard P. Gabriel, at onwa…@oopsla.acm.org.

http://oopsla.acm.org

Program Committee

Geoff Cohen, Cap Gemini Ernst & Young
William Cook, Allegis
Walter Fontana, Santa Fe Institute
Richard P. Gabriel, Sun Microsystems
David West, New Mexico Highlands University

Hello Everyone,

I would first like to thank all the new members of STIC who have joined
since November.  I look forward to adding many more.

STIC now sports a new logo.

See:  http://www.stic.org/logo/sticlogo.jpg

Jason Jones
www.whysmalltalk.com
www.stic.org

Newsgroupies:

Here’s an awesome post from the XP mailing list, by James Goebel:

on 1/16/03 12:18 AM, silver at sil…@hire.com wrote:

jg>> I support a democratic approach to this "hard work" problem.
jg>> For developers who only want to pair for 1/2 or 3/4 of the day,
jg>> offer part-time positions.

> in my humble experience, there is only 5 or so hours of pure programming that
> can be done in a day by a person before their quality starts to lag.

In my experience, sometimes disguised as humble, I would not only agree with
you but I would suggest that for the typical programmer 5 hours of actual
programming would be extraordinary.

As I have watched several organizations experiment with Extreme Programming,
it has become clear to me that paired-programming is not an activity but
instead a skill that needs to be learned.  As developers improve their
paired-programming skills I have been amazed to find that they simply spend
more time focused on value delivery every day.  I often wonder if this is
because it gives the hours that they spend at the office more meaning while
providing more consistent reinforcement from their peers.

That said, it is not my expectation for developers to be hand-cuffed
together.  But, I do consider a key metric for any XP team is the amount of
time that the collaborative space is not filled with activity.

I suspect that it is also important to note three things to better
understand my perspectives…

  1. Developers are not paid to code, but to complete story cards.
  2. It has been a while since I was salaried and assumed that my
     employer should pay for my self-directed study.
  3. Long hours of "pure programming" (writing code), without
     performing integration, writing tests, or comparing designs
     with others on the team is probably a bad sign.

As you suggest, team members have many other responsibilities beyond typing
lines of code!  

> However, there is also lots of time to be spent on things like helping
> customer/QA types make functional tests,

In our environment we encourage the developer to be paired with the
customer/QA person, and/or perhaps even another programmer.

> keeping up with email and
> bureaucratic stuff about their job

For all the companies that find this type of activity valuable it makes
sense to me to encourage this as a solo activity.  However, if the email or
bureaucratic stuff adds value to the project I would really like to have at
least two developers be familiar with the information.

> answering questions from other developers,

This should be happening all the time, and often involves pairs of pairs or
higher order interactions.

> talking to the customer about potential future stories, talking to other
> developers about design directions, reviewing things that other people have
> checked in, assisting any documentation authors, etc etc.

We agree that all of this should be on-going.  Although I am curious about
the "reviewing" practice.

> I would not rate programmer’s salaries on programming time alone, but just
> keep an eye for obvious slack. If someone isn’t pulling their weight, it is
> usually known to everyone.

I am not worried about how much time is spent programming.  Instead I am
interested in how much time is being spent working on completing customer
value within the context of our defined process.  Writing acceptance tests,
talking about story cards, estimating stories, integrating code, and
answering questions all qualify as completing customer value.  And these
activities are usually performed in groups.

When developers spend a significant proportion of their day alone in a cube
or off working by themselves, I assume that their organization is
reinforcing and rewarding such behavior.  Typically this is the case even
while they also "promote" experimenting with paired-programming.

In the organizations that have been the most emotionally rewarding for me to
work with, the team spent the vast majority of their day working together.
When teams have found paired-programming really draining and difficult to do
all day, it has been my observation that this usually has more to do with
individual Code Ownership than any other issue.

I hope that better clarifies my Extreme point of view about actually working
all day.  Perhaps others who have participated in teams that pair most of
the day would care to chime in…

James Goebel
www.menloinnovations.com

Hi,

I’m working now on a project, which is similar to an application
firewall. It’s a piece of software that listens to a certain protocol,
processes the messages and produces a different set of messages (drops
some, modifies some).

Who’s the user in this case? How do you suggest to write a story?

Let’s take an example, how do you write the following requirement in a
story format:

Process messages of type M, remove the header H1 and replace with H2.

Thanks,
Doron

Hi,

Many times you have design requirements that are not relevnat directly
to the user but more to the developers. Things to keep in mind when
developing or designing the software. How do you suggest to capture
them?

Examples:
– It should be possible to easily replace technology X with technology
Y
– System should scale by CPUs
– System should scale by machines
– System should be portable

Thanks,
Doron

I need to find data about XP diffusion, but I can’t find it in web.

I need data about success percentage of XP adoption, number of society using
XP in the world (and in Italy), and future trend of this metodology. In
other words, there should be inquiry about use of XP and its future…

Could someone help me? I can’t find them…
T.I.A.

Bye bye,
Massimo

How come most people are talking about methodology, when they should say
method instead. But the nature of the word, there can be only one
software-development-methodology; everything else is methods.

I know this is no XP-related question, but still a good one, i believe.

Hello Everyone,

Why Smalltalk now has a newsletter that I will be sending to those on the
Why Smalltalk mailing list.  For a time, I will post them on Why Smalltalk.

To join the mailing list, simply fill out the form on the main page of Why
Smalltalk or email me at jjo…@whysmalltalk.com

Newsletter can be found here:
http://www.whysmalltalk.com/newsletter/newsjan1803.htm

Jason Jones
www.whysmalltalk.com
www.stic.org

XP minifaq:
<http://homepage.mac.com/keithray/xpminifaq.html>

Extreme Programming (XP) is a set of principles and practices for
developing software. It has been described as a "high-discipline,
low-overhead methodology". XP has developers programming in pairs,
writing tests to verify all code, and continuously refactoring code to
improve the design. To quote Kent Beck: "XP is a starting line. It asks
the question, ‘How little can we do and still build great software?’"

comp.software.extreme-programming is a newsgroup for discussing this
methodology. (Not Windows XP, not your extremely hard programming
work/homework questions.)

NOTE: Every newsgroup has one or two trolls; after the regulars start
ignoring them, they feed on newbies. Please read the troll faq before
responding to taunting or obvious mis-statements of the facts.
  <http://www.hyphenologist.co.uk/killfile/anti_troll_faq.htm>

XP FAQ: <http://www.jera.com/techinfo/xpfaq.html>

XP and related Books:  [My comments in brackets]

"Extreme Programming Explained: Embrace Change"
by Kent Beck;
ISBN 0-201-61641-6  
[I recommend others, see below.]

"Refactoring: Improving the Design of Existing Code"
by Martin Fowler;
ISBN 0-201-48567-2
[Strongly recommended.]

"Pair Programming Illuminated"
by Laurie Williams, Robert Kessler
ISBN 0-201-74576-3
[Strongly recommended.]

"Planning Extreme Programming"
by Kent Beck, Martin Fowler;
ISBN 0201710919
[Recommended.]

"Extreme Programming Installed"
by Ron Jeffries, Chet Hendrickson, and Ann Anderson;
ISBN 0201708426
[Strongly recommended.]

"Extreme Programming Applied"
by Ken Auer, Roy Miller;
ISBN 0-201-61640-8
[Strongly recommended.]

"Agile Modeling"
by Scott W. Ambler;
ISBN 0-471-20282-7
[Recommended.]

"Questioning Extreme Programming"
by Pete McBreen
ISBN 0-0-201-84457-5
[Recommended. Explains assumptions and context of XP.]

"Agile Software Development"
by Alistair Cockburn;
ISBN 0-201-69969-9
[Recommended. strong points about communication being the core of agile
methods.]

"Agile Software Development Ecosystems"
by James A. Highsmith III;
ISBN 0201760436
[Good overview of XP, Scrum, Crystal, FDD, etc.]

"Powerful Project Leadership"
by Wayne Strider
ISBN 1567261477
[Recommended people-skills for manager/coach/leader]

"Quality Software Management" volumes 1 – 4
by Gerald M. Weinberg
ISBN
[Volume 4 suggests several techniques compatible with XP]

"Extreme Programming Examined"
by Giancarlo Succi and Michele Marchesi;
ISBN 0-201-71040-4

"Extreme Programming Perspectives"
by Marchesi, Succi, Wells, Williams
ISBN 0-201-77005-9

"Extreme Programming Explored"
by William C. Wake;
ISBN 0-201-73397-8

"Extreme Programming in Practice"
by James W. Newkirk and Robert C. Martin;
ISBN: 0-201-70937-6

"Java Tools for Extreme Programming"
by Richard Hightower, Nicholas Lesiecki;
ISBN 0-471-20708-X

"Adaptive Software Development"
by James A. Highsmith III;
ISBN 0-932633-40-4

"Agile Software Development with Scrum"
by Mike Beedle, Ken Schwaber;
ISBN 0130676349

Web sites:

Extreme Programming: A Gentle Introduction
<http://www.extremeprogramming.org/>

XP magazine:
<http://www.xprogramming.com/xpmag/index.htm>

XPlorations:
http://xp123.com/xplor/

XP Universe 2001 Papers:
http://www.xpuniverse.com/2001/xpuPapers.htm

XP Test Frameworks:
<http://www.xprogramming.com/software.htm>

Junit test framework for java:
<http://www.junit.org/>

Agile Testing:
<http://www.testing.com/agile/index.html>

Wiki Pages on XP:
<http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap>

The Agile Modeling (AM) Home Page
<http://www.agilemodeling.com>
<http://www.agilemodeling.com/essays/agileModelingXP.htm>

Martin Fowler’s Refactoring Home Page
<http://www.refactoring.com>

Object Mentor publications:
<http://www.objectmentor.com/resources/articleIndex>

Pour des informations en français sur XP :
<http://www.design-up.com>

L’eXtreme Programming, avec deux études de cas.
Jean-Louis Bénard, Laurent Bossavit, Régis Médina, Dominic Williams
Editions Eyrolles, 2002; ISBN: 2-212-11051-0
<http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13
=9782212110517>
<http://www.amazon.fr/exec/obidos/ASIN/2212110510/>