This book is about a marriage of two compatible yet unlikely
partners. Extreme Programming (XP) is a software development
methodology that enables users, business people, programmers, and
computers to communicate effectively. Perl is a dynamic programming
language that lets an XP team embrace the inevitable change caused by
effective communication. Perl is the fixer and doer of the pair, and
XP is the organizer and facilitator. Together they help you build
robust software applications efficiently.

Like any good marriage, the partners of Extreme Perl support each
other. For example, XP asks business people to write acceptance
tests, and Perl lets the business people use their own language and
tools for the tests. Much of Perl only happens when the program runs,
and XP asks programmers to define what is supposed to happen in unit
tests before they write the program. In this book, you'll see other
examples where Perl reinforces XP and vice versa. This mutual support
system is what makes Extreme Perl applications robust.

This book invites Perl programmers and their customers to take a fresh
look at software development. Customers, and business people in
general, will learn how XP enables customer-programmer communication
for efficient and flexible requirements gathering. Programmers will
see how XP's focus on teamwork, incremental testing, and continuous
design allows them to take pride in their craft. The numerous
examples demonstrate Extreme Perl in action, including the development
of a complete, end-to-end application in the last chapter.

To Business People and Users

XP combines your project responsibilities into a single official role:
the customer. That's the extent of the
formalism. You don't need to learn use-case modeling, object
modeling, or even fashion modeling. You write your requirements on a
piece of paper with pen. You even get to draw pictures, although
the programmers would prefer you didn't use crayon.

As the customer, you have the responsibility to speak in one voice.
You can discuss the requirements as much as you like, but in the end,
you write down a simple, clear requirement in your own language,
called a story.
Any disagreements need to be settled during the
planning game, where you and the programmers hash
out what needs to get done and how long it is going to take.

XP lets you change your mind. That means you have to hang around the
programmers--something that may take getting used to. Programmers are
terrible mind readers, and your immediate feedback is necessary when
they get the requirements wrong or you realize a requirement isn't
quite right.

Best of all, you get to see progress right away. The programmers
do the simplest thing that could possibly work,
and believe it or not, this actually produces a working program in a
matter of weeks. There's nothing better than seeing your requirements
embodied in software to ensure you are getting what you want, and that
you get what you are paying for. Everybody is motivated by a working
product in use.

To Programmers and Their Managers

The programming role is quite broad in XP. Programmers are
responsible for listening to the customer, and reacting to the dynamic
requirements of the customer's world.

With XP, you get to be real. No more fudged estimates or wild
guesses. If the customer adds a complex requirement, like
internationalization, right in the middle of the project, it's clearly
not for free, and you get to say how long it will take.

XP managers are coaches and
trackers. The programmers do all the work, and
the coach gives sage advice while sipping martinis. If all goes well,
the tracker has a passive role, too. XP's 12 simple practices add up
to a lot of checks and balances. Sometimes the coach and tracker must
remind the programmers how to use the practices effectively, however.

Code is the core artifact of an XP project. You have to like to code
to do XP. Fortunately, Perl is fun and easy to code. XP adds a
modicum of discipline to Perl coding practices that enables you to
code faster and better.

XP is reflective. The code gets better, because you
refactor it frequently. This means you get to
fix the bad code in the project that usually everybody is afraid to
touch. With XP, you might not be so afraid. You and your
pair programming partner have lots of tests to
ensure you don't break anything while refactoring.

The goal of refactoring is to represent concepts once and only
once. Perl lets us do this more easily than other
languages. Extreme Perl code can be quite compact without
obfuscation--rather the opposite. The code often evolves into what I
call a subject matter oriented program
(SMOP).

Subject matter oriented programming distills the essence of the
problem into a little language. The SMOPs in this book are plain old
Perl. There's no need to invent new syntax. Sometimes you may need
to think differently to understand a SMOP unless you already are
familiar with declarative programming, which is
quite different than traditional imperative
programming--what most programmers learn in school.

You need to know Perl fairly well to read many of the examples. I
explain the examples without going into much detail about the Perl
syntax and semantics. You may need to keep your favorite Perl
reference book within reach, for example, to undertand how
map works.

One last thing: the some of test examples use the
bivio OLTP Platform (bOP),
an open source application framework developed by my company
(http://www.bivio.biz).
If you write a lot of tests, you need tools to help you write them
quickly and clearly. bOP employs SMOP to simplify unit and acceptance
tests. I'm not trying to sell bOP to you--it's free anyway--but to
demonstrate SMOP in testing. This book explains just enough of bOP to
read the examples.

How to Read This Book

This book explains Extreme Perl to both programmers and business
people. I also attempt to convey the Extreme Perl experience through
examples and personal anecdotes. The book covers Extreme Programming
(XP) in detail, so no prior experience is necessary.

If you are a top-down thinker, I recommend you read this book front to
back. Bottom-up thinkers may want to start at the last chapter and
work backwards.

As noted in the previous section, the Perl code in this book is
advanced. The programming examples are not complex, that is, they are
short and contain only a few concepts. However, the code may appear
complicated to some programmers. If you are familiar with functional
programming and object-oriented Perl, the examples should be clear.
If not, you may want to peek at the last chapter which describes
functional programming. The references throughout the book may be
helpful, too. The object-oriented aspects are not all that important,
so you should be able to understand the examples without
object-oriented experience.

Typographical notes:
I note acronyms that are used in the XP and Perl communities
throughout this book, but I use their expansions so you don't have to
memorize them.

Acknowledgments

This book was a collaborative project. Many people contributed to
make this book better. Any errors and omissions are my own
despite the barrage of corrections from the from the following people.
If I left out your name, please accept my apologies.

To Joanne, thank you for your love, support, knowledge, active
participation, and editing skills. This book would not have happened
without you.

To Ben and Aidan, thanks for accepting the million just a minute's,
for manufacturing thousands of story cards, and for teaching me about
life and people in the process. Living with children and practicing
XP have much in common.

To Paul Moeller, thank you for being a brilliant business partner,
friend, and programmer. Thanks for teaching me why there is no busy
work in programming, and for saying and not saying what you thought
about this book.

To Ion Yadigaroglu, thank you for the thousand conversations, your
support, and for believing in me. And, for having the courage to
leave the programming to the programmers.

To Martin Lichtin, thank you for explaining that every layer of
indirection creates a new software problem, and for helping me wade
through myriad software problems over the years.

Thanks to the bivions: Danny Ace, Annaliese Beery, Greg Compestine,
Eric Dobbs, Eric Schell, David Farber, Justin Schell, and Tom Vilot.
You took part in my crazy experiments, listened patiently to my
lectures and diatribes, and taught me much about programming,
teamwork, and having fun.

Thanks to Johannes Rukkers for teaching me about applications
programming in large organizations, and for the many enlightening
conversations at the James Joyce and elsewhere.

Thanks to Rob Ward for gallantly giving up your true name at O&A,
for years of patient guidance and support, and for smashing through
the illogic and unEnglish in the many drafts of this book.

Thanks to Stas Bekman, Justin Schell, and Alex Viggio for pair
programming with me in the last chapter. You kept me on task, and
helped me avoid complexity.

I'd also like to thank my many mentors over the years:
Jon Bondy,
Pete Bonham,
David Cheriton,
Tom Lyon,
Jim Madden,
Richard Olsen,
Andrew Schofield,
and
Roger Sumner.
Bits of your wisdom are contained herein; I hope I got them right.

Finally, thanks and my deepest sympathies to the family of Pete
Bonham. You allowed me to enter your lives at such a difficult time.
Pete's death was a driving factor in this book, and his life's work
guides me regularly.

Life and work are a series of successes. It just so happens that XP
makes them more visible, but you have to choose to celebrate them.