Have fun, and build something cool.
-- Pete Bonham
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
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
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
One last thing: the some of test examples use the
bivio OLTP Platform (bOP),
an open source application framework developed by my company
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.
The first part of this book is about the non-programming aspects of
Extreme Perl: the why
the what (Extreme Programming
and the how (Release Planning,
There is some code in
but everybody should be able to read it.
The last chapter (It's a SMOP) is an end-to-end Extreme
Perl example that combines XP, Perl, and SMOP.
may want to scan this chapter and read the conclusions at the end.
The second part of this book contains numerous programming examples
from the real world. The following chapters show you what it is
like to do Extreme Perl:
It's a SMOP.
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
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
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
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
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.
Thanks to the many other reviewers who contributed the volumes of feedback
that made my writing and examples more readable and correct. The
reviewers in alphabetical order were:
I'd also like to thank my many mentors over the years:
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.
Boulder, CO, US