XP Explained

This week we begin the re-read of Kent Beck’s Extreme Programing Explained, Second Edition (2005). I remember the first time I read Extreme Programing Explained (First Edition), it was flying back and forth between Cleveland and Los Angeles.  It took two flights and then a lot of time to consider. XP Explained provides not only an explanation of Extreme Program, but also a philosophy for XP and Agile.  The 189 pages are organized into two sections and 25 relatively short chapters and are crammed with information and ideas. I used a whole highlighter on the book during my first read (the pages are now florescent yellow.  The book was written by Kent Beck, one of my heroes even before Agile.  The Second Edition now has Cynthia Andres joining Mr. Beck.

Extreme Programming Explained: Embrace Change, Second Edition begins with two forwards and a preface.  I freely admit that my natural tendency is to plow through reading forewords and prefaces.  In this case, it was interesting to compare the difference between the forewords from the first and second editions, both written by Erich Gamma.   The main point is that the second edition is a full rewrite.  Gamma says that Beck applied the XP paradigm of “stay aware, adapt, change.”

Extreme Programming reflects a philosophy of adapting and changing based on the environment that the developer is operating in.  In the Preface, Beck rephrased the message that he used to open the first edition.  The message Beck opens the book with is that:

  1. No matter the circumstances you can always improve.
  2. You can always start improving with yourself.
  3. You can always start improving today. 

The message of XP Explained is one of hope, discipline, deliberate practice, and improvement.

Chapter 1 – What is XP?

Chapter 1 is the context from which the rest of the book builds.  During my original read, I remember breezing through this chapter to get to the “beef.” However, over the years, I have returned to this chapter to reground my understanding of Beck’s vision.  In the second edition, Beck builds on his initial definition: “XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.” In the second edition, Beck provides a list of attributes to augment the original definition. 

  • XP is lightweight
  • XP is a methodology
  • XP can work with teams of any size
  • XP adapts to vague or rapidly changing requirements.

The obvious difference is the recognition that XP can be used with teams of any size. As interesting is the implicit recognition in the last attribute that XP is can be applied even when requirements are well understood.  The newer definition recognizes that XP is both a style and philosophy of software development that can be applied to any scenario. The overarching philosophy provides a container to hold a set of complementary principles that support a set of techniques.  

Beck suggests philosophically that in XP you don’t prepare for failure, rather you play all out to win.  XP is a philosophy and methodology that is based on a mentality of sufficiency. Rather than focusing on the constraints, a project lives within, XP focuses on delivering software and continuous improving regardless of constraints. All efforts and projects have constraints, spending too much time worrying about constraints is a distraction from the goal of the work.  

XP addresses many of the risks in the software development process, such as:

  1. Schedule slippage by leveraging short release cycles.
  2. Avoidance of not delivering anything due to project cancellation by the use of small releases that make business sense.  
  3. Chances that the system goes “sour” by leveraging continuous automated testing.
  4. High defect rates by having both programmers and customers write tests.
  5. Business needs are misunderstood by including business-oriented people as first class members of the team.
  6. Business needs change before delivery is addressed through the shortened release cycle.
  7. False feature rich releases are avoided by planning that includes the business and an insistence on working on the highest priority items first.
  8. Staff turnover is reduced by allowing programmers to take the responsibility of estimating their own work and then to perform to those estimates. The frustration of being asked (or told) to do the impossible is reduced improving the working environment.

When I was flying to Los Angeles reading Extreme Programming Explained the first time, I was a little bit too impatient and breezed through Chapter 1.  However, it is important because it provides the contextual underpinning for XP.  Understanding the definition and philosophy of XP  provides a foundation for beginning to explore XP in more depth next week.

Programming Notes:  Next week we will begin Section One: Exploring XP.  Currently, I am planning to re-read two chapters per week even though they are relatively short. Please get a copy of Extreme Programing  Explained, Second Edition (this link will support the blog and podcast), read along and comment!