How Time Flies

A quarter century of Extreme Programming

It has now been a quarter century, more than 40% of my lifetime, and over 70% of my career as a software developer and coach.

It was in October 2000 that I first heard about Extreme Programming (XP) while, coincidentally, I was pairing with a colleague designing and coding a Java framework.

I had visions of “totally rad” dudes on skateboards, coding while swilling Mountain Dew, not knowing that the originators were older software geeks not unlike myself who were just as tired of the issues we faced using the heavy and ineffective software processes of the 1990s.

I had just left a gig on a very large government program after two years of struggling against a “big binder of requirements” approach to building systems, although that group was beginning to see the light and made the radical decision to try using the Rational Unified Process (RUP). Like most RUP implementations, it didn’t really provide much, if any, value.

Before that gig I had been a contract developer and had cultivated a reputation of getting shit done. I loved collaborating with and solving problems for the people consuming the work I was doing. That’s what had gotten me hooked on software development back in high school and still motivates me almost 45 years later!

While that one gig had been an arduous and painful experience, I left it with the feeling that there had to be a better way to deliver software in a team environment. I can credit that pain with opening my mind to something more “extreme”.

Back to October 2000… after my colleague had quipped that our pairing session reminding him of “this Extreme Programming thing he had heard of”, we stopped at a local bookstore (remember those?) over lunch. We found two books about XP: Extreme Programming Explained (the White Book) and Extreme Programming Installed (the Pink Book).

Since both of us were commuting to work by public transit, we had ample opportunity to read the books over the next few days. I remember getting to the office in the morning and we’d excitedly review what we had read the day before! The values, principles and practices of XP resonated deeply with both of us, mainly because we used many of them before when we had been successful. Having direct and daily access to the people consuming the work (the Customer role) was something I had done since the first system I wrote for my high school basketball coach in 1982! Having the team co-located was a successful approach I had seen on a gig in 1992. Pair programming was what that colleague and I were doing when he mentioned XP! Working iteratively and constantly planning based on feedback was just how I worked, with the exception of that large government program.

The only really new practices to me were Test-Driven Development and the System Metaphor.

The System Metaphor was a way to create a common language used by everyone in the team. For example, the original XP project was a payroll system at the Chrysler car company, so they used an assembly line metaphor for classes, methods and variables. This practice, though, has since been supplanted by the concept of “Ubiquitous Language” from Domain-Driven Design.

As for Test-Driven Development (TDD), it was and still is the most misunderstood practice from Extreme Programming. No, it never meant writing all of the tests before writing any code. No, it never meant writing all the code and then writing tests for it. No, it never meant, “Don’t think about what you’re going to build before starting”.

TDD kind of warped our brains back in late 2000, but my colleague and I decided to give it a try. We’d think about and even do some whiteboard design of what we needed to build. We’d write a single test, which should fail because there was no code to implement it. We’d then write just barely enough code to make the test pass. We’d then determine if any refactoring of either the production code or the tests was needed. Rinse and repeat.

If you aren’t ambidextrous, imagine trying to write with your opposite hand. That’s what TDD felt like at first. However, since my colleague and I had the “buddy system” in place to provide some peer pressure to stick with the approach, we kept at it. After a week it began to feel more comfortable. After a month, it felt perfectly natural! We were guiding our development by expressing the desired functionality in tests. We refactored the code as we worked to ensure that it was as good a design as possible. We did so safely because we had a safety net of tests to support us. The constant dopamine hits of seeing tests pass was thoroughly addictive, and still is today!

---

I won’t bore you with all of the trials and tribulations of the ensuing 25 years, but there are a few key themes that emerged over that time.

1. The values, principles and practices of XP have, for the most part, stood the test of time.

2. Lean principles and XP go together like peanut butter and jam.

3. Scrum, without the technical practices of XP, is not a sustainable way to deliver software.

4. To paraphrase Martin Fowler, scaling XP is the last thing you should do.

One of the objections to XP is that it’s focused at the team level and doesn’t have any mechanism for deciding whether a project or product should be worked on at all. This is where you can apply Lean principles at the product or portfolio level to determine what work a group should be doing. Lean’s focus on optimizing flow is also hugely valuable in helping teams determine how best to work together.

And one final point. Those of us who have practiced XP since those early days have evolved over time. Many groups no longer use iterative development, opting instead for continuous delivery. Estimation using Story Points and Velocity has been replaced by simply counting completed stories and techniques like Monte Carlo forecasting. As the Agile Manifesto says, “We are uncovering better ways of developing software by doing it and helping others do it”. That’s as true in 2025 as when it was written in 2001.

---

Over the past year or so, I’ve seen what appears to be a resurgence in interest in the technical aspects of delivering software. This could be related to what can best be described as the fall of Scrum during the same period. Interestingly, when XP is brought up as a replacement, I hear & read about people saying that it’s too prescriptive and heavy.

We members of the software counterculture of the late 20th and early 21st centuries just smile, nod and write another failing test.