Extreme Programming in practice at Autotrader

Recently, I attended XConf in Madrid, a one-day software conference hosted by Thoughtworks. Throughout the day, I noticed a series of recurring themes, all seemingly connected to Agile development. After speaking with other attendees, I realised these ideas were actually part of a related concept known as Extreme Programming (XP). This was my first time I was formally introduced to XP, sometimes jokingly referred to as eccentric programming, and it got me thinking about how we apply these practices at Autotrader, more specifically within the Core Engineering team I’m part of. Core Engineering is focused on maintaining the core Java web services that power the Autotrader platform.

XP was one of the first agile methodologies, developed by Kent Beck in the early 1990s. It consists of a range of practices grouped into five distinct areas: planning, managing, designing, testing, and coding. Each area has its own set of guidelines and rules. We’ll focus on a selection of these practices, exploring what they are, how we apply them at Autotrader, the reasoning behind them, and the trade-offs involved.

Planning

First, we’ll focus on planning. A key aspect of planning is iteration planning. An iteration is a short and time-boxed period where a team will aim to achieve a number of tasks. Iteration planning is a meeting held at the start of each iteration to plan the tasks that will be worked on during the iteration. During this meeting, a selection of user stories are chosen to work on, a user story is a short description of a software feature written from the perspective of the end user. The user stories are then prioritised based on the value they deliver to the stakeholder. In some of the more traditional XP approaches, each user story is broken down into a series of smaller tasks, described in the developers’ own language. Developers then estimate the complexity of each task using a point-based system. These estimates are done blindly to avoid anchoring bias. Each developer chooses a number in secret, and all reveal their estimates simultaneously. The purpose of this process is to spark discussion. For example, if one developer estimates a task as an 8 while the others choose a 3, it highlights a gap in understanding. This difference triggers a conversation to clarify assumptions and align understanding. Once a consensus is reached, the story is considered ready to be picked up by a developer.

Within Core Engineering, we begin our week on Tuesday mornings with an iterative kickoff meeting (IKO). During this meeting, the technical leads or senior figures will bring a selection of user stories for discussion. We then estimate them using a planning poker system, which helps highlight uncertainty early, encourages shared understanding, and keeps everyone engaged throughout the meeting. This approach isn’t without its drawbacks. Developers can sometimes focus on finding the “correct” estimate rather than delivering actual value. It can also be time-consuming, subjective, and inconsistent. For example, two stories both estimated at five points may look very different in practice. That’s why regular calibration is essential. Ultimately, planning poker should only be used for sparking meaningful conversation and building a shared understanding of the work ahead, not as a precise measure of time or a tool to track performance.

Coding

One of the core principles of XP is the coding standards. Pair programming is an aspect of this. Pair programming is a technique where two developers work together on the same code whilst sharing a single computer. There are two roles: the driver, who writes the code and focuses on syntax and immediate problem-solving, and the navigator, who reviews each line as it’s written, keeping an eye on the overall direction and spotting potential bugs. Pair programming offers several benefits. It often produces higher-quality code, as two sets of eyes can catch mistakes and consider design decisions more carefully. It also encourages knowledge sharing across the team, helping members understand different parts of the codebase and reducing bottlenecks. For junior developers, pairing with more experienced colleagues provides a valuable learning opportunity.

However, pair programming isn’t without challenges. It can be tiring to maintain focus together for extended periods, and it often takes more time upfront, although this can be offset by fewer bugs and architectural mistakes later. Success also relies on strong communication and collaboration skills, which can be demanding.

Within Core Engineering, we strongly promote pair programming. All production code should be developed using pair programming and reviewed by another pair. While this principle is central to how we work, there are obviously practical constraints, such as scheduling conflicts which can occasionally make pairing difficult. Pair programming also plays a key role in accelerating the growth of junior developers. It enables them to get hands-on experience and contribute to production code from day one, rather than spending their first few months solely focused on fundamentals. This approach helps new team members build confidence and familiarity with our codebases much faster. Within Core Engineering, quality matters more than speed so we can afford to pair. Often teams don’t have the resources to properly implement pairing.

It is important to note that pair programming is a skill that takes time to learn, you should aim to find a cooperative way to work that considers both yours and your partners ideas. It shouldn’t be a hierarchical relationship, two people should be working together as equals even if one has more experience.

Another important rule within XP is that code must be written to agreed standards. At first, this can feel restrictive, but the goal is only about making the codebase accessible to everyone on the team and reducing technical debt.

We format our code consistently using a plugin that runs during the build, and we also follow a set of predefined coding standards. For example, we don’t allow nested ternaries because they hurt readability. We try to avoid the ! operator, as it can be easy to miss when reading code, and prefer clearer alternatives such as object.isNotEmpty() over !object.isEmpty(). We also ban the use of var, as it can reduce clarity and make the code harder to understand.

These guidelines aren’t imposed without discussion. If a team member has a suggestion or improvement, it’s raised in an open forum and discussed as a group. Once we reach a consensus, the rule is formalised and added to our coding guidelines document.

Managing

Most developers will be familiar with the concept of a stand up meeting. It was popularised in the early 1990s by a number of agile pioneers, including Kent Beck and Jim Coplien. Today, many developers treat stand ups as the default, they happen every day and are never questioned. However, it’s worth revisiting why stand ups were a core part of XP in the first place, and why they’re still used today.

If we consider a typical project management meeting, many attendees often have little to contribute. This leads to large amounts of developer time being spent for very limited communication. Stand ups were designed to solve this problem. Their purpose is focused, team communication: sharing progress, discussing blockers, raising issues, and keeping everyone aligned. Originally, stand-ups were done with the team literally standing in a circle to encourage brevity. With the rise of remote work, they’re now commonly held over video calls.

During a stand-up, developers aim to communicate three key things: what they worked on yesterday, what they plan to work on today, and any problems or blockers that might slow them down.

Within Core Engineering, we do daily stand-ups at around 9:30am. They usually last between 5 and 20 minutes. The focus is on making sure everyone knows what they’re working on, that everyone has a pairing partner, that progress is being made, and that blockers or issues are surfaced early. It’s also a good way to stay connected as a team.

There are some aspects of XP that we don’t follow within Core Engineering, and one of those is measuring project velocity. Velocity is an indicator of how much work is completed in an iteration and is calculated as the sum of the story points for completed stories. It relies on the false assumption that story points are consistent and accurate.

For teams that do measure project velocity, stakeholders use this metric during their IKO meetings, which was mentioned earlier when discussing planning poker. Stakeholders are able to select user stories for the next iteration based on the previous iteration’s velocity. For example, if 25 story points were completed last week, stakeholders could select stories totalling 25 points for the current week. This approach comes with several downsides. Firstly, project velocity naturally fluctuates over the lifecycle of a project and often decreases once a system is in production due to increased maintenance. When velocity is closely tracked, it can easily shift from being a thermometer to becoming a target. This can lead to inflated story points, developers favouring quicker and easier work, and important refactoring being deprioritised. It also discourages spikes, experimentation, and the reduction of technical debt, all of which are core principles of XP. Velocity also assumes that story points remain consistent and stable over time. When treated as a performance metric, it can create unnecessary pressure and lead teams to focus on maximising quantity rather than producing quality code.

Designing

A common problem in development is that someone will occasionally have an idea but won’t be sure whether it’s worth pursuing, or even whether it’s possible at all. We don’t want to invest time trying to perfect something that may never work, so we use what are known as spikes.

A spike is a simple investigation to a hard problem. It’s built to answer a specific question or reduce uncertainty. The code that is produced isn’t intended to be production-ready, and it’s expected that it will be thrown away. The goal is to reduce risk before committing time and effort to a full implementation.

In practice, a spike is a short, time-boxed investigation. The output is learning and understanding, not features or polished code. Spikes should not be refined or moved to production. By keeping them focused and limited, they prevent teams from getting stuck on an an idea that may not be viable. Overall, spike solutions give teams greater confidence before investing in a full story and help support better technical decision-making.

Simplicity is another core aspect of XP. Over the past couple of years, I’ve worked on a couple greenfield projects . A greenfield project is a brand new application, built without constraints from older systems.

One of the main risks with greenfield work is over-engineering. With no existing boundaries, it’s easy and tempting to design for worst-case scenarios, build for hypothetical use cases, or add features that might be needed rather than ones that are actually required. This leads to unnecessary complexity. We aim to keep applications simple and focused.

In practice, that means designing for what is required today, not for every possible future scenario. Adding flexibility or functionality too early makes systems harder to understand and change. Extreme Programming is explicit on this point: simplicity is key, and functionality should not be added before it is needed.

Simplicity is subjective. What feels simple to one developer may be complex for another. Some XP literature describes simplicity using four qualities which can help you measure the simplicity of code despite its subjectivity. Your code should be testable, easy to navigate, understandable, and explainable. A developer should be able to quickly test it, find what they’re looking for, and clearly explain what the code does, why it exists, and why it is structured the way it is.

While Core Engineering doesn’t explicitly follow this terminology, the principle remains the same. We aim to keep our designs as simple as possible and resist adding premature complexity.

Testing

Testing is a crucial part of XP. Core engineering works on business critical applications, and if our system breaks or contains a bug, it can create critical downstream issues. That’s why we need to be confident when releasing changes. For this reason, all code must have passing unit tests, integration tests and acceptance tests. Unit tests are a core component of XP, and you should be writing tests for all classes within an application, ideally before writing the code itself, this is known as test-driven development. Unit tests are developed alongside the code, they give confidence, reduce bugs, and help explain the code to developers. By reading a test, you can get a general idea of what the code does. They also make refactoring safer, as you can verify that changes to internal structure or logic don’t introduce unexpected side effects. In short, XP states that all code should have passing unit tests, an idea that we follow within core engineering.

Acceptance tests are another crucial part of XP. These tests verify that the application or feature meets the business requirements, usually from the perspective of a stakeholder or user. Instead of focusing on specific code, acceptance tests check whether the system functions correctly from a user’s perspective, can they do what they need to do? Within Core Engineering, we use a behaviour driven development (BDD) framework called Cucumber to write our acceptance tests. Cucumber tests are written in an English-esque language called Gherkin, this also allows non-technical stakeholders to understand how the application works and what it can do without having to read the code. Like unit tests, acceptance tests run as part of the build, and no change can be released until all acceptance tests are passing. You should generally write an acceptance test for each user story.

Conclusion

Overall, I’m glad I attended the conference, primarily because it introduced me to XP. It encouraged me to explore the principles behind XP and research how we apply them at Autotrader. Practices such as stand-ups and pair programming are treated as the status quo, without much thought as to why we do them. Researching XP encouraged me to question these assumptions and to better understand the benefits and trade-offs behind these practices.