“Even programmers can be whole people in the real world. XP is an opportunity to test yourself, to be yourself, to realize that maybe you’ve been fine all along and just hanging with the wrong crowd.”
Kent Beck – Extreme Programming Explained – 2nd Edition
As of the writing of this article, Kent Beck’s book is 17 years old. The first edition actually came out 5 years earlier, so it’s been a little over 20 years since the Extreme Programming methodology was born—only slightly longer than the famous Agile Manifesto of 2001. Not surprisingly, Kent Beck is one of the original signers of the Agile Manifesto, and we can see much of this in the very objective of Extreme Programming:
“The goal of Extreme Programming (XP) is outstanding software development.”
Kent Beck, Preface to Extreme Programming
“Kent continues to challenge my views on software development. […] I suggest you do the same and accept the XP invitation to improve the way you develop and create outstanding software.”
Erich Gamma, Foreword to Extreme Programming
Erich Gamma is a member of the well-known “Gang of Four,” and one of the authors of Design Patterns – Elements of Reusable Object-Oriented Software, published roughly 27 years ago and still a mainstay on every serious programmer’s bookshelf.
What is Extreme Programming (XP)?
We could spend a whole day defining it. So let’s see what its creator has to say, in his book on the subject:
- XP is giving up old, ineffective technical and social habits in favor of new ones that work.
- XP is fully appreciating yourself for total effort today.
- XP is striving to do better tomorrow.
- XP is evaluating yourself by your contribution to the team’s shared goals.
- XP is seeking to meet specific human needs through software development.
These declarations are profound, and many reading them for the first time are struck, just like I was. As programmers, we’ve felt the need to humanize software development for decades. We have the sense of working long hours without achieving our goals. We keep doing things the same way and failing at every step. We assume we work better alone, whereas the reality is we move faster, and with better results, when we do things by two, or as a team.
But then why do we keep repeating the same ineffective patterns? These are deep questions that Extreme Programming answers, believe me. And if not, believe Kent Beck, Erich Gamma, Martin Fowler, Robert C. Martin, and the numerous other programming luminaries who implemented XP and proved that it works.
From its inception, the very name Extreme Programming was meant to pack a punch. This was much-needed. At the time, programmers lacked many of our contemporary ways of collaborating. Of course, some still stick to the old methods, but overall, the changes are obvious. Agile was a turning point in the way our profession interacts and works together.
3 pillars: Values, Principles and Practices.
To make these declarations into a workable methodology, XP is founded on three pillars: values, principles, and practices.
Values are the reasons for implementing a practice, and the reasons you start talking about XP in the first place. If you realize that XP values go against your own values, it will be hard to keep learning about XP. But before deciding anything, reread the citations at the beginning of this article. They may just light the fire of real change inside you.
Values are intrinsic and reside deep within all of us, and many programmers already share XP values. It’s that feeling in your gut that something is right or wrong, at least on the level of professional ethics.
Practices, on the other hand, are clear and concrete. They mean what they mean: a way of doing something. The problem with practices is that they need to have a meaning, whereas values are too abstract and generic to be reflected clearly in a practice.
For example, say you prize communication as one of your professional values. In that case, daily meetings would be one example of an important practice. Through them, you demonstrate the importance you place on communication. Even having daily meetings that last for hours would be coherent with this value. But then other important elements may be missing. This is where principles come in handy.
Principles are the glue that bind values and practices together. For instance, if you value economics, you know that someone is paying for everything you do. So, you scale your practices to match your values according to your professional principles.
As a result, daily meetings should be short and effective. They promote communication and are maximally efficient for the company, respecting both a value and a principle at once. In fact, combining XP’s values and principles is the very basis of its practices.
Let’s take a quick look at the list of XP values, principles, and practices, as Beck describes them in his more-evolved second edition:
XP also has a list of corollary practices that are, quite possibly, where things start to get “extreme.” But we’ll stick with primary practices for now, and leave corollary practices for a future article.
In the next edition of our Extreme “Coincidence” series, we’ll explore values and principles on a deeper level, and then tie them together in describing how we implement certain practices. Our last article will look at what Extreme “Coincidence” really is. Why the quotation marks? You’ll find out soon…
In the meantime, if you’d like to dive deeper, you can explore the Agile Alliance website.
