Paired programming... not two off-topic I hope

22 Jun 2006 - 10:30am
8 years ago
14 replies
808 reads
jbellis
2005

The thread on agile (adaptive) methodology inspired me to ask, are any of those adaptive shops out there using paired programmers, and does it work?

I learned only recently (http://menloinstitute.com/) that this is apparently a tenet of extreme programming in the extreme... wherein developers work exclusively in pairs and only one types at a time. It strikes me as brilliant, but too radical for the mainstream, thus my curiosity.
Thanks,
www.jackbellis.com

Comments

22 Jun 2006 - 10:53am
Becubed
2004

On 22-Jun-06, at 11:30 AM, jackbellis.com wrote:
> The thread on agile (adaptive) methodology inspired me to ask, are
> any of those adaptive shops out there using paired programmers, and
> does it work?

As it happens, I'm currently sitting with 6 developers who are paired
into three teams. I have monitor envy, as they're working in front of
widescreen 30" LCDs, but that's a bit off-topic...

This is with a client who's two months into their very first
experiment with Agile/XP. And I tell 'ya, it's working out
wonderfully. The team has been enormously productive and the
developers appear to be enjoying themselves immensely, as well.

Folks were hesitant about paired programming at first, but willing to
give it a shot. I understand they've hit a groove where the person at
the keyboard is focused on the details of the moment, while the
partner thinks ahead a bit more strategically as well as performing
an on-the-spot code review. It took a while to get comfortable with
putting yourself "out there" so obviously, but that doesn't seem to
be an issue anymore.

FYI that I'm on board as the interaction designer and am also playing
the XP-termed role of "customer". This means I work with their
product manager to write "stories" to describe the required front-end
functionality for each two-week iteration. I'm also pumping out
wireframes & prototypes.

The project was preceded by about 6 weeks of concept development and
geurilla usability testing, which this client hired us to do. That
helped to get the underlying framework in place, which is a
shortcoming of hardcore XP that suggests you dive right in (I
believe). Since beginning the work, I've tracked one iteration in
front of the developers, working out the UI details of what they'll
be coding next.

This has been my first experience with Agile/XP. I'm liking it.

--
Robert Barlow-Busch
Practice Director, Interaction Design
Quarry Integrated Communications Inc.
rbarlowbusch at quarry.com
(519) 570-2020

This e-mail message (including any attachments) is intended only for
the use of the individual to whom it is addressed and may contain
information that is privileged, proprietary, confidential or subject
to copyright. If you are not the intended recipient, you are
notified that any use, dissemination, distribution or reproduction of
this communication is strictly prohibited. If you have received this
communication in error, please notify the sender and delete this e-
mail message immediately.

22 Jun 2006 - 11:13am
Meredith Noble
2010

> This is with a client who's two months into their very first
> experiment with Agile/XP. And I tell 'ya, it's working out
> wonderfully. The team has been enormously productive and the
> developers appear to be enjoying themselves immensely, as well.

Robert, I completely agree with this. Also, along with increased productivity,
one of the best things about pair programming is the tremendous amount of
learning opportunities that arise for programmers. By working so closely with
another person you can learn everything from new keyboard shortcuts and IDE
features to new programming concepts and techniques.

My first professional programming job was at a company that had been using
Extreme Programming (XP) for several years. It was the best place I could have
possibly gone as a beginner, because I was able to pair with more experienced
coders and soak up information right away. This is in direct contrast to some
of my friends, who ended up isolated in cubicles, banging their heads up
against problems they simply didn't have the skills to overcome. I became a
much better programmer because of the constant mentoring I received from others
in my project room.

I also have a theory that a pair programming environment is easier to work in as
a female. I haven't validated this beyond my own experience, but as someone who
thrives on personal interaction I think that the constant back-and-forth of
pair programming was ideally suited to my personality. It's so great to bounce
an idea off a partner and be able to grow it into something better as a team.

Best,
Meredith

22 Jun 2006 - 11:15am
Robert Hoekman, Jr.
2005

I used to do a little paired programming myself. We only had a couple of
developers, so it was always the same people, but it worked great. we got a
lot done in a very short amount of time - far more than if we had worked
alone, and it made programming far more enjoyable.

-r-

On 6/22/06, jackbellis.com <jackbellis at hotmail.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> The thread on agile (adaptive) methodology inspired me to ask, are any of
> those adaptive shops out there using paired programmers, and does it work?
>
> I learned only recently (http://menloinstitute.com/) that this is
> apparently a tenet of extreme programming in the extreme... wherein
> developers work exclusively in pairs and only one types at a time. It
> strikes me as brilliant, but too radical for the mainstream, thus my
> curiosity.
> Thanks,
> www.jackbellis.com
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

22 Jun 2006 - 11:22am
Becubed
2004

On 22-Jun-06, at 12:09 PM, Meredith Noble wrote:
> Robert, I completely agree with this: one of the best things about
> pair
> programming is the tremendous amount of learning opportunities that
> arise...
> It's so great to bounce an idea off a partner and be able to grow
> it into something
> better as a team.

Wise words, Meredith. And thanks for sharing your experience with XP.

The lesson above applies equally well to interaction design. Think
about projects in which you've been a sole designer vs. those in
which you worked with another. My best work is *always* as a result
of pairing up with someone else, for the reasons Meredith describes
above.

Ironically, the XP project I'm involved with right now has me as the
sole designer. So while I'm surrounded by programmers working in
teams... I'm sitting all by my lonesome. <cry>

We need more designers on our team here at Quarry, so if you're
interested or know of someone who'd like to work in Waterloo,
Ontario, Canada, please send 'em my way! See a recent job post at:

http://www.triux.org/2006/04/job-user-experience-designer/

--
Robert Barlow-Busch
Practice Director, Interaction Design
Quarry Integrated Communications Inc.
rbarlowbusch at quarry.com
(519) 570-2020

This e-mail message (including any attachments) is intended only for
the use of the individual to whom it is addressed and may contain
information that is privileged, proprietary, confidential or subject
to copyright. If you are not the intended recipient, you are
notified that any use, dissemination, distribution or reproduction of
this communication is strictly prohibited. If you have received this
communication in error, please notify the sender and delete this e-
mail message immediately.

22 Jun 2006 - 11:30am
Becubed
2004

On 22-Jun-06, at 12:15 PM, Robert Hoekman, Jr. wrote:
> I used to do a little paired programming myself. We only had a
> couple of
> developers, so it was always the same people, but it worked great.
> we got a
> lot done in a very short amount of time - far more than if we had
> worked
> alone, and it made programming far more enjoyable.

I'm told that overall productivity is supposed to drop a bit (15%
comes to mind?) in terms of lines of code written per time period.
Apparently you're trading this off for better quality and a shorter
project duration in the end due to fewer rewrites and bug fixes. Can
anyone confirm this?

Anyway, despite this assertion, everyone here has been surprised at
the speed the programmers have been able to achieve -- most
especially the programmers themselves. And they swear the quality's
higher too.

I suspect this speed is attributable in large part to a core tenet of
XP: "Do the simplest thing possible." This means the programmers
write the simplest code *that meets the expressed requirements*.
Traditionally, they'd attempt to make the code more flexible to
account for new requirements in the future; but lessons from software
development indicate this tradeoff isn't worth making generally.

As a side effect, I've had many wonderful conversations in which
programmers push back on UI designs. "Can't we make it any simpler?
Is that feature *really* needed? If not, let's forget about it."
Fantastic stuff, that.

--
Robert Barlow-Busch
Practice Director, Interaction Design
Quarry Integrated Communications Inc.
rbarlowbusch at quarry.com
(519) 570-2020

This e-mail message (including any attachments) is intended only for
the use of the individual to whom it is addressed and may contain
information that is privileged, proprietary, confidential or subject
to copyright. If you are not the intended recipient, you are
notified that any use, dissemination, distribution or reproduction of
this communication is strictly prohibited. If you have received this
communication in error, please notify the sender and delete this e-
mail message immediately.

22 Jun 2006 - 12:12pm
Daphne Ogle
2005

On Jun 22, 2006, at 9:22 AM, Robert Barlow-Busch wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> On 22-Jun-06, at 12:09 PM, Meredith Noble wrote:
>> Robert, I completely agree with this: one of the best things about
>> pair
>> programming is the tremendous amount of learning opportunities that
>> arise...
>> It's so great to bounce an idea off a partner and be able to grow
>> it into something
>> better as a team.
>
> Wise words, Meredith. And thanks for sharing your experience with XP.
>
> The lesson above applies equally well to interaction design. Think
> about projects in which you've been a sole designer vs. those in
> which you worked with another. My best work is *always* as a result
> of pairing up with someone else, for the reasons Meredith describes
> above.
>
> Ironically, the XP project I'm involved with right now has me as the
> sole designer. So while I'm surrounded by programmers working in
> teams... I'm sitting all by my lonesome. <cry>

This is a great point Robert! I worked in an XP environment for
Menlo Innovations (happens to the be the link pointed to in the start
of this message) as a High-tech Anthropologist (HTAs), http://
www.menloinstitute.com/method/anthropology.htm. The developers are
paired and so are the HTAs. The HTA's play a similar role as the
customer described in XP. The twist is that HTA's focus on really
understanding the users and their business through ethnography and
empathic research. We even worked off story cards. I've worked in
several environments and Menlo was by far the most fun, interesting,
growing and productive place I've worked (if they were only in the
Bay area :)). The designs we produced were also extremely
interesting and usable.

I'm pushing a similar practice in my group at Berkeley. So far, my
design colleagues say they are learning a ton and feel like are
designs are right on.

Daphne Ogle
Interaction Designer
University of California, Berkeley
Educational Technologies Services
daphne at media.berkeley.edu

22 Jun 2006 - 2:56pm
Adrian Howard
2005

On 22 Jun 2006, at 16:30, jackbellis.com wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> The thread on agile (adaptive) methodology inspired me to ask, are
> any of those adaptive shops out there using paired programmers, and
> does it work?

Oh yes. Very much so.

I'm in the process of trying to convert my new $WORK folk to the idea
having worked in pairing environments previously

It's even better if you expand it from it just being programmer-
programmer pairs. Having programmer-usability folk pairs to pass on
the knowledge (both ways). Have programmer-customer pairs to help
define requirements and write sensible tests. etc.

Works /very/ well in my experience - as long as people are willing to
give it a fair trial.

Cheers,

Adrian

22 Jun 2006 - 3:04pm
Adrian Howard
2005

On 22 Jun 2006, at 17:22, Robert Barlow-Busch wrote:
[snip]
> Ironically, the XP project I'm involved with right now has me as the
> sole designer. So while I'm surrounded by programmers working in
> teams... I'm sitting all by my lonesome. <cry>
[snip]

Go sit with them - teach them :-)

Adrian

22 Jun 2006 - 3:11pm
Oleh Kovalchuke
2006

> It's even better if you expand it from it just being programmer-programmer
pairs.

Hear, hear.

An example from my experience is Interaction Designer-Usability Engineer -
perfect complement of skills. Some of the most fruitful ideas came to me
when I have worked very closely on daily basis with Usability Engineer.

--
Oleh Kovalchuke
Interaction Design is Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

On 6/22/06, Adrian Howard <adrianh at quietstars.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
>
> On 22 Jun 2006, at 16:30, jackbellis.com wrote:
>
> > [Please voluntarily trim replies to include only relevant quoted
> > material.]
> >
> > The thread on agile (adaptive) methodology inspired me to ask, are
> > any of those adaptive shops out there using paired programmers, and
> > does it work?
>
> Oh yes. Very much so.
>
> I'm in the process of trying to convert my new $WORK folk to the idea
> having worked in pairing environments previously
>
> It's even better if you expand it from it just being programmer-
> programmer pairs. Having programmer-usability folk pairs to pass on
> the knowledge (both ways). Have programmer-customer pairs to help
> define requirements and write sensible tests. etc.
>
> Works /very/ well in my experience - as long as people are willing to
> give it a fair trial.
>
> Cheers,
>
> Adrian
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

22 Jun 2006 - 3:31pm
Adrian Howard
2005

On 22 Jun 2006, at 17:30, Robert Barlow-Busch wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> On 22-Jun-06, at 12:15 PM, Robert Hoekman, Jr. wrote:
>> I used to do a little paired programming myself. We only had a
>> couple of
>> developers, so it was always the same people, but it worked great.
>> we got a
>> lot done in a very short amount of time - far more than if we had
>> worked
>> alone, and it made programming far more enjoyable.
>
> I'm told that overall productivity is supposed to drop a bit (15%
> comes to mind?) in terms of lines of code written per time period.
> Apparently you're trading this off for better quality and a shorter
> project duration in the end due to fewer rewrites and bug fixes. Can
> anyone confirm this?

That sounds about what people normally say.

Subjectively - I feel a much more productive when pairing. It's much
hard to get side tracked into yak shaving type activities.

For those who want an introduction to the topic there's a book-in-
progress excerpt over on James Shore's blog about programmer pairing
at <http://www.jamesshore.com/Agile-Book/pair_programming.html> with
some references at the end.

[snip]
> As a side effect, I've had many wonderful conversations in which
> programmers push back on UI designs. "Can't we make it any simpler?
> Is that feature *really* needed? If not, let's forget about it."
> Fantastic stuff, that.

It is isn't it ;-)

One of the things I love about agile development environments is that
it puts to bed the myth that developers are asocial idiots who can't
possibly know/understand/help with usability issues. The problem's
not with the programmers. The problem is with the deeply
dysfunctional development environments/methodologies that isolate
developers from real users/customers behind N layers of management /
architects / project managers and that reward them for the wrong things.

Cheers,

Adrian

22 Jun 2006 - 4:49pm
Robert Hoekman, Jr.
2005

> It's even better if you expand it from it just being programmer-programmer
> pairs.

I second that.

-r-

22 Jun 2006 - 6:01pm
Christopher Fahey
2005

> The lesson above applies equally well to interaction design.
> Think about projects in which you've been a sole designer vs.
> those in which you worked with another. My best work is
> *always* as a result of pairing up with someone else, for the
> reasons Meredith describes above.

Hell yeah. Information architecture is all about designing and then
second-guessing your own designs, constantly. Having another person paired
with you and commenting on your work, even working on the very same pages,
is invaluable.

If budget is a problem -- if you can't afford to have two IAs on a project
-- it might help to even have an IA intern shadowing you on a job. It
doesn't take a seasoned pro to help with a surprising number of IA
decisions.

-Cf

Christopher Fahey
____________________________
Behavior
http://www.behaviordesign.com
me: http://www.graphpaper.com

22 Jun 2006 - 6:01pm
dmitryn
2004

On 6/22/06, Robert Barlow-Busch <rbarlowbusch at quarry.com> wrote:

> I'm told that overall productivity is supposed to drop a bit (15%
> comes to mind?) in terms of lines of code written per time period.
> Apparently you're trading this off for better quality and a shorter
> project duration in the end due to fewer rewrites and bug fixes. Can
> anyone confirm this?

I can't confirm or deny this, but I would not be altogether surprised.
One of XP's other main tenets is ruthless refactoring, which generally
reduces the number of lines of code, all other things being equal.
LoC's have been pretty much discarded as a measure of productivity by
current software engineering thought, anyway.

Dmitry

23 Jun 2006 - 9:43am
jbellis
2005

Robert,
Regarding the apportionment of XP's benefits to categories of causes, I
suspect a different explanation. I see the breakout like this:

40% Reducing Rework:
Quality control by all its many names. I like "rework," the word I've heard
for Detroit-style car production... where they attempt to fix failures of
process and design in a nasty scene at the end of the production line. It
worked pretty well for 80 years, but those days are done.

40% Improving Proficiency:
Running the gamut from little techniques that programmers learn from one
another, to the most meaty "domain" knowledge, it's all the same phenomenon:
a radically enhanced manner of training that creates a snowball of expertise
instead of private fiefdoms.

20% Feature Simplicity:
It's hard for me to believe that this is a big factor. Yes, developers will
occasionally "gold plate" (do work that is not specifically requested) but
I've never accepted the notion of feature bloat. Most features I've seen
added have been motivated by reducing tasks to the fewest actions. I'll bet
that as an XP shop gains speed, they simply add more automation faster.
(Simplicity of technical solutions [elegance] is another matter, and
probably belongs to the other two categories.)

-Regards,
Jack

----- Original Message -----
From: "Robert Barlow-Busch" <rbarlowbusch at quarry.com>
Subject: Re: [IxDA Discuss] Paired programming... not two off-topic I hope

> I suspect this speed is attributable in large part to a core tenet of
> XP: "Do the simplest thing possible." This means the programmers

Syndicate content Get the feed