Pair programming and extreme programming are not interchangeable

by Andy Lester

An open letter to Charles Babcock (cbabcock@cmp.com)


In the May 17, 2004 issue of InformationWeek, you made a serious, yet
all-too-common mistake.


Extreme programming... pairs up two developers, one to produce code
and the second to review the coder's work, ask whether it meets
business requirements, and work closely with business employees.



What you've described is not extreme programming, but pair programming,
which is only one facet of XP, but is not in itself XP. Unfortunately,
pair programming is the practice that people seem to latch on to
first, probably because it's the most radical and easiest to dislike.
XP's other principles and practices include simple design, continuous
integration and testing, writing tests before code, closer interaction
with customers, group code ownership, code reuse, shorter release cycles
and incremental delivery.


There are number of excellent resources on the web and in print to
help gain a more thorough understanding of XP. Three great places to
start include:


  • Extreme Programming Pocket Guide

    by chromatic (O'Reilly)


    An excellent, inexpensive overview of XP. This should be called
    "Extreme Programming: The Manager's Briefing."

  • Extreme Programming Roadmap

    http://www.c2.com/


    A Wiki maintained by Ward Cunningham, one of the big daddies of XP.
    Constantly updated by folks in the trenches making XP work.

  • Extreme Programming Installed

    by Ron Jeffries, Ann Anderson, Chet Hendrickson (Addison-Wesley)


    There are about a dozen XP books from Addison-Wesley, but I like
    this one best, as it focuses on making XP happen in practice.



This misconception is especially distressing in a magazine like
InformationWeek ("Business Innovation Powered By Technology") read by
IT managers for whom your article might be their only exposure to XP.
I'd hate to think of the number of IT managers who hand-wave XP as
"that thing where you have twice as many developers writing the code,"
or something similarly short-sighted. Perhaps a followup article touching
on the less flashy aspects of XP would help your readers out by pointing
out the other, more obviously valuable concepts.


Thanks,

Andy Lester

What other misconceptions of XP get propagated?