In my hand I am holding a little white book that, fourteen years ago, changed the software world forever. The title of that book is: Extreme Programming Explained; and the subtitle is: Embrace Change. The author is Kent Beck, and the copyright date is 1999.

The book is small, less than 200 pages. The print is large and widely spaced. The writing style is casual and accessible. The chapters are short. The concepts are simple.

The implications were an Earthquake whose tremors haven’t even begun to die down.

Chapter 10, which begins on page 53, lays out the 12 practices that caused our industry to erupt into controversy; and spawned a revolution that has changed everything about the way we write software. Those practices are:

• The Planning Game: Nowadays known as SCRUM. The idea that software is produced in short increments from a prioritized list of work items.

• Small Releases: The notion that deployments should be frequent and incremental.

• Metaphor: Finally crystalized by Eric Evans in his book Domain Driven Design. The notion that the structure of the system is based upon a simple mental model of the problem domain.

• Simple Design: The notion that it is best to keep the system as simple as possible at all times regardless of what we fear about the future.

• Testing: The notion that programmers, and customers, write automated tests that verify that the production code actually does what they think it should. Nowadays we call this Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD).

• Refactoring: The notion that the internal structure of software can, and should, be continuously improved.

• Pair Programming: The notion that members of a team cannot be a team if they work separately. To be a team they must regularly collaborate, at the keyboard. In so doing they share knowledge sufficient to cover for each other as team members should.

• Collective Ownership: The notion that the code belongs to the team, not to the individual.

• 40 Hour week: The notion that teams who consistently work overtime are failing.

• On Site Customer: The notion that someone from the business, who is responsible for requirements, must be readily and consistently available to the programming team.

• Coding Standards: The notion that the team adopts a consistent style in their code emphasizing cleanliness and communication.

Controversial?

Strange isn’t it? This doesn’t seem all that controversial does it? But fourteen years ago it was wildly controversial. Indeed, it was so controversial that whole books were published describing how this couldn’t possibly work, and how all the proponents were knuckle-dragging, money-grubbing, nitwits who never wrote a line of code in their lives and….

Ah, but I shouldn’t let those old feelings overtake me… Because, after all, they’re gone – and we’re still here.

Look at those twelve practices. Which ones don’t you do? Most of you, my gentle readers, likely do most of these practices on a regular basis. While it’s certainly a stretch to say that they have become universal, it is by no means a stretch to say that they are now considered main-stream. What’s more, those teams that don’t do all these practices today, are trying to move towards them. These practices have become an ideal, a goal to be achieved as opposed to a heresy to be reviled.

The Churn

The last fourteen years have been strange. The Agile movement, which was spawned out of the controversy over Extreme Programming, skyrocketed into success, and was subsequently taken over by the project managers who all but pushed the programmers out. We’ve seen the creation, the wild success, and the corresponding (and predictable) impotence, of certifications. We saw the adoption of the planning game (i.e. SCRUM) without the other eleven practices; and we saw that strategy fail – becoming what Martin Fowler called: Flaccid Scrum. We’ve experienced continuous and vocal process churn as consultants and authors split and competed over Kanban, Lean, and every new project-management prefix-of-the-day. We’ve seen the growth of the software craftsmanship movement, and the slow degradation and dilution of the Agile meme.

But in the midst of all that hype and churn, those twelve practices have remained. Some of their names have changed a bit. 40 Hour Week became Sustainable Rate. Testing became TDD. Metaphor became DDD. Small Releases became Continuous Integration and Continuous Deployment. But despite these changes the practices remain very much as they were described fourteen years ago.

We also saw the name Extreme Programming fade almost entirely out of use. Very few people use that term nowadays. Some still use the abbreviation XP; but for the most part the name has evaporated. It is very rare for me to hear a team describe what they do as Extreme Programming, even when they are practicing all twelve practices as described. The names change. The practices remain. The practices are persistent.

Amidst the churn, the hype, the controversy, the bluster and blather. Amidst all the chaos of humans jockeying for position over one-another. Amidst all the messiness of human avarice, passion, and pride. Amidst all that politics, the practices persist.

Stable Values

I believe the practices persist because they are based on a firm foundation of stable values. Values that Kent Beck described in Chapter 7 on page 29 of his book:

• Communication
• Simplicity
• Feedback
• Courage.

I could try to argue why these are the right values; but I think they speak for themselves. What software craftsman would reject any one of those values? What software craftsman would not strive to ensure that each one of those values were represented in their work? These values are values of software craftsmanship.

I could try to argue that the twelve practices embrace and exemplify these values, but their persistence – despite the churn and dissolution of the names and movements that surrounded them, is evidence enough.

Success

Extreme Programming succeeded! It succeeded beyond the wildest dreams of its proponents. It succeeded because it survived the controversy of its birth and the subsequent, and inevitable, churn of its advocacy. It succeeded because it outlived even its own name!

Extreme Programming has succeeded in the way that Structured Programming succeeded. Nobody even thinks about structured programming any more – they just do it. Nobody even thinks about Extreme Programming any more, we are all just trying to do it.

That’s success! An idea succeeds when it outlives the movement that spawns it and simply becomes part of our everyday lives. That’s SUCCESS!

Looking Back

So today, in these last weeks of 2013, take a moment to reflect back on 1999. A time when Kent Beck wrote a ground-breaking book. A book that changed everything. Look back and remember: Extreme Programming; and recognize it as the core of what we, today, simply think of as:

Good Software Practice.