🚀 The XP Effect: How eXtreme Programming Influenced Modern Methodologies 🔥✨

⏩ Introduction

Extreme Programming (XP), which first appeared in the late 1990s, marked a profound change in how teams conducted software development. With its focus on teamwork, flexibility, and continual improvement, XP provided a welcome change from conventional development methods. The essential ideals, concepts, and practices of XP have not only endured through the years but have also served as the basis for many of the most effective methodologies and practices that are currently in use.

XP is definitely one such approach that has irrevocably changed the face of software development, together with Lean and a few others.

We will jump into the world of eXtreme Programming today, to explore its tremendous impact on contemporary approaches. We will look at how XP's core concepts — simplicity, feedback loops, and customer involvement — have influenced the software people in the ideation of popular frameworks like Agile, DevOps, and others.

🔥✨ Let's dive in and see why every software person should know XP! 🔥✨

⏩ XP 101

XP is a style of software development focusing on the excellent application of programming techniques, clear communication, and teamwork which allows us to accomplish things we previously could not even imagine.

XP is about social change. It's about letting go of habits and patterns that were adaptive in the past but now get in the way of us doing the best work; it’s a path of improvement to excellence for people coming together to develop software. Some distinguishing points of eXtreme Programming are:

short development cycles, resulting in early, concrete, and continuing feedback
incremental planning approach, which quickly comes up with an overall plan
flexibly schedule the implementation of functionalities, responding to changing business needs
reliance on automated tests written by programmers, customers, and testers to monitor the progress of development
reliance on oral communications, tests, and source code to communicate system structure and intent
reliance on an evolutionary design process that lasts as long as the system
reliance on the close collaboration of actively engaged individuals with ordinary talent
reliance on practices that work with both the short-term instincts of the team members and the long-term interest of the project

XP can be described this way: a lightweight methodology based on addressing constraints in software development - only do what you need to do to create value for the customer; it can work with teams of any size and adapts to vague or rapidly changing requirements.

XP means giving up old habits of working for new ways tailored to today's reality.

👑 Values, principles, and practices

Making values explicit is important because, without values, practices quickly become activities performed for their own sake but lacking any purpose or direction.

Practices are evidence of values. Values are expressed at such a high level that I could do just about anything in the name of value. Practices are clear.

Principles bridge the gap between values and practices. Principles are domain-specific guidelines for life.

The values of XP are:

Communication: What matters most in the software development team is communication. Communication is important for creating a sense of team and effective cooperation.
Simplicity: the most intensely intellectual of the XP values. Creating a system simple enough to gracefully solve only today's problem is hard work. The right question is "What is the simplest thing that could possibly work?".
Feedback: A direction does not remain valid for long, whatever we are talking about. Change is inevitable, but change creates the need for feedback. "Wouldn't it be easier just to do it right in the first place?" Of course, it would, except for three things:
- We may not know how to do it right
- What's right today may be wrong tomorrow
- It might take so long that circumstances change and that solution becomes not valid
The idea is to shorten the feedback cycle to minutes or hours instead of weeks or months.
Courage: Even if people involved in software development are not soldiers, they definitely feel fear in their work. How they handle that fear dictates whether they are working as an effective part of the team or not. Courage can be a dangerous value if not counterbalanced with other values: doing something without regard for consequences is not effective teamwork. But: the courage to speak truths fosters communication.
Respect: If members of a team don't care about each other and what they are doing, XP won't work. Every person whose life is touched by software development has equal value as a human being: the contribution of each person to the team needs to be respected.

Values are intended to balance and support each other: improving communication helps achieve simplicity by eliminating unneeded or deferrable requirements from today's concerns; achieving simplicity reduces the amount of stuff that you need to communicate, etc.

Anyway, Values are too abstract to directly guide behavior; they don't provide concrete advice about what to do, so to gap the bridge between values and practices we need a bridge: this bridge is made by the principles. Some examples of principles are Humanity, Economics, Improvement, Diversity, Flow, Failure, Quality, and Baby steps.

Those principles will then lead to Practices: practices are the kind of things you will see XP teams doing daily, and they only make sense if related to principles; pairing just to make your boss happy is frustrating, but if you recognize its values in communication, feedback, simplicity, courage and respect it makes a lot of sense.

Practices are situation dependent: if the situation changes, you will choose different practices to meet those conditions. Values don't change, and principles can be used to figure out something new. Applying a practice is a choice: XP offers a collection of practices that work and work even better together, and they have been used before, some examples are Pair Programming, Weekly Cycle, Quarterly Cycle, Continuous Integration, Test-First Programming, and Incremental Design.

If you want to go deeper into XP values, principles, and practices, the best thing to do is to read the book from its creator Kent Beck, Extreme Programming: Explained.

🍀 Only good things come with XP

There’s a very cool quote from an Italian movie I saw once - it’s called Amore, bugie e calcetto (that means “Love, lies and futsal”), a super easy Italian movie, not something special actually, but this single quote is very smart, IMHO.

In the movie, a group of friends play a futsal championship together while problems happen in their own personal life; one of them will soon have a child and is very scared of it, and ask for tips from the wise man in the team that always helps others.

At first, he is not able to say something very useful, but in the end, he says:

I’ve met a lot of people that regret marriage, but I’ve never met anyone who regretted becoming a parent. This must mean something!

I can say something similar for the main Agile practices and methodologies - but especially for XP, it is so true!

I was lucky enough to meet people in very different contexts, with completely different backgrounds, sharing thoughts and working together around Agile principles, frameworks, and anything related to that.

The only topic that doesn’t cause fighting debate, but only positive discussion, is XP. I’ve met a lot of people that regret Scrum, Kanban, and even TDD sometimes, but I’ve never met someone that learned XP and then complains about it!

It’s not only about XP being great (TDD also is, for example) - the XP book from Kent Beck makes the concepts very clear, yet most of them (values and principles) are quite abstract and high-level. I think that the main reason why XP makes everyone agree is that values & principles are pretty solid.

Maybe some practices may be used in some contexts and not in others, but on values & principles there is 99% agreement from everyone because it’s just common sense formalized.

How can someone say that “communication” or “respect” value doesn’t make sense?

To end, one last reflection: XP, with its values, principles, and practices can be easily reconducted to the top-notch practices and methodologies existing today. Some examples are:

Test-Driven Development, the evolution of the practice of Test-First Programming
Trunk-Based Development, the way to implement Continuous Integration properly
Objective Key Results, which can easily be reconducted to Quarterly Cycle practice

Do you see? Everything started from XP, so back to basics to learn it and you will understand the foundation of the greatest programming practices existing today!

Until next time, happy coding! 🤓👩‍💻👨‍💻

Dan’s take 🙋🏻‍♂️

I will never forget the first time I heard about eXtreme Programming: I knew nothing about it and my mind immediately went to the image of Software Developers typically offered by movies and TV series - I connected the word “extreme” to developers coding all night without a break, achieving impressive result.

Very naive, isn’t it? 😃 At the time, I could never imagine how far from the truth I was!

That’s why one of the things I like the most is the explanation of the name “Extreme Programming”: the foundational idea of XP is to take all the things that Kent Beck saw working in the past and take those things to their extreme in order to maximize the positive value they bring. Extreme, indeed, but in a positive way.

If it hurts, do it more - extremizing that “more”. Weird, eh? Here are some examples:

merging a branch hurts? merge daily, at least once per day
releasing in production every month hurts? do it daily, multiple times per day

Extreme Programming is a completely different approach to Software Development from what existed before, but the fact is: it works amazingly!

I’ve seen teams with average technical skills doing amazing things thanks to XP, I even managed one and we were able to deploy multiple times per day for 2 years, with a completely automated pipeline based on pushing and tagging, managing a BE, FE, Mobile app + some ancillary microservices. Only a couple of bugs were able to reach production and, more important considering it was a new product in a relatively new business, we continuously adapted to changes and made a lot of experiments, while deploying important and impacting features in a progressive way without big-bang releases.

Compared to other teams I worked with, where we had some of the highest technical skills I’ve ever seen in a single person, we were achieving more and faster.

Of course, context matter, and without any numbers, this is not concrete as it should be, but it’s important for me to state clearly that I’ve seen how XP can work and how it can maximize the outcomes of a team - and it’s amazing.

The last thing I want to emphasize is that XP is more related to people and communication than technicalities. Practices are not very technical - the most technicals are those related to tests (Test-First, Code & Tests) - most of the practices are focused on handling team collaboration and work balance, reducing chances of errors due to moving in baby steps and releasing so often that the changes you release are very easy, increasing the happiness of people so that teams can last long, etc.

XP remember us that while we use technology and computer to achieve our work, it’s still a work made of people.

Extreme Programming is one of the most astonishing discoveries to make in Software Development - it can completely change your view on this job.

With XP, we can unlock a better way to develop Software, that is proven to be successful and more sustainable for both people and business.

Go Deeper 🔎

📚 Books

eXtreme Programming: Explained - Every team can improve. Every team can begin improving today. Improvement is possible―beyond what we can currently imagine. Extreme Programming Explained, Second Edition, offers ideas to fuel your improvement for years.
eXtreme Programming: Examined - This book brings together the proceedings of the first global XP conference: the collected "best practices" wisdom from the world's leading XP practitioners. This collection brings together case studies, experiences, and research related to all aspects of XP.
eXtreme Programming: Installed - The book consists of a connected collection of essays, presented in the order the practices would actually be implemented during a project. Ideal as a start-to-finish tutorial and quick reference, the book demonstrates exactly how XP can promote better communication, quality, control, and predictability.

⏩ Introduction

⏩ XP 101

👑 Values, principles, and practices

🍀 Only good things come with XP

Dan’s take 🙋🏻‍♂️

Go Deeper 🔎

📚 Books

📩 Newsletter issues

📄 Blog posts

🎙️ Podcast episodes

👨🏻‍🏫 Online courses