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 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.

The first part of this book is about the non-programming aspects of Extreme Perl: the why (The Problem), the what (Extreme Programming and Perl) and the how (Release Planning, Iteration Planning, Acceptance Testing, Tracking, and Pair Programming). There is some code in Acceptance Testing, 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. Non-programmers 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: Coding Style, Logistics, Test-Driven Design, Continuous Design, Unit Testing, Refactoring, and 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 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.

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: Jim Baker, Kent Beck, Tom Brown, David Bruhweiler, Sean Burke, chromatic, Phil Cooper, Ward Cunningham, Bryan Dollery, Jeff Haemer, Ged Haywood, Joe Johnston, Walter Pienciak, Chris Prather, Lewis Rowett, Michael Schwern, Jeremy Siegel, and Mike Stok.

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.