Extreme Programming - Most and Least Used Practices

I've recently been going through the textbook Engineering Software Products by Ian Sommerville and was interested in Sommerville's take on the most and least followed practices of Extreme Programming.

I want to list 10 Extreme Programming practices (fundamental ones as noted by Sommerville) here and give my take on them.

What is Extreme Programming

XP (extreme programming) is a term coined by Kent Beck in 1998 to describe his new Agile project management methodology.

Agile was created to move software development away from the more sequential approach of the waterfall model to a more iterative methodology. The Waterfall model worked well in the older aerospace, building, and military industries, but was tough to do with software.

This is largely due to software's more dynamic nature. It's hard to predict every requirement prior to development, and without user feedback throughout the process you may ship a product that doesn't meet all the user's needs.

Agile, a more iterative approach where features would be released every 2-4 weeks (a sprint) was the answer. Extreme programming wasn't like an extreme sport, rather the idea was to push the best practices of the time to "extreme" levels to make software development more efficient.

The 5 Most Widely Adopted

According to Sommerville, these 5 are the most used XP practices.

Test-first Development

Most developers will know this as TDD (test driven development). The goal is to write your tests before you write any code. When writing tests you provide an input (if needed) and expect an output.

Sommerville states that these tests clarify the purpose of the code, and that all new code should not break anything that already exists.

I agree with this and believe that the tests, if written concisely, can explain everything you need to know about the code. Well written code is easy to write tests for, so it forces developers to follow best practices.

I often find myself writing the initial tests, but sometimes getting wrapped up in the development of the code and not writing the tests needed for full coverage. Luckily modern coverage checks exist but it is a good practice to write the tests so the next developer can more easily make changes.

Refactoring

Sommerville explains that refactoring should be done as soon as improvements are found.

Ideally this makes sense but other priorities exist throughout the sprint. Critical security vulnerabilities should be addressed ASAP, but for other refactors it's probably best to save them for a time when feature development has slowed down.

Incremental Planning

These may also be known as User Stories and you'll generally find these within the Jira ticket you're working on.

Sommerville mentions these are from customers and they are done by priority and time available. I completely agree that user stories are extremely valuable for communicating user needs to everyone including the developers.

They typically follow this format in Scrum:

As a < type of user >, I want < some goal > so that < some reason >.

Continuous Integration

The practice of Continuous Integration is one of the most adopted practices by a company looking to be Agile.

Work is integrated to production when the task is complete. All tests should pass and the code should be reviewed.

Modern CI/CD tools have allowed this process to be much easier than it was in the past.

Small Releases

Small Releases are another core concept for all agile companies I've worked.

The idea here is to release the MVP (minimally viable product) and then release frequent feature updates every sprint cycle (2-4 weeks).

Small releases allow for faster feedback.

The 5 Least Adopted

Sommerville notes that most companies don't follow one Agile methodology over another, but rather pick and choose from various methodologies (Scrum, XP, etc).

In being picky, most companies are less inclined to do the following 5 practices (though I believe some are worth the effort).

Simple Design

Simple design can also be summed up by the acronym YAGNI (you aren't gonna need it).

Sommerville notes that according to XP, this means that developers should only code the requested features. His retort is that extra, potentially complex code is often necessary as users aren't fully aware of the system that powers the product.

I agree that user stories alone don't guide technical choices, but I think the philosophy of simple design / YAGNI is one that influences all areas of software engineering. Whether its code, database, or architecture any means to simplify the design but keep the functionality will be appreciated by everyone on the team.

On-site customer

This concept seems to be a product of it's time, where teams greatly benefited by having a customer / user on site to quickly provide feedback on new features.

Sommerville claims this is time consuming and may not be worth the customers time.

With the wide range of available tools to aid communication this should be less of an issue now. Being able to receive direct feedback via a Zoom call or async via a survey makes having an on site customer unnecessary. Not to mention the data gained from tracking user interactions can largely automate the feedback process.

Sustainable pace

When working sequentially (waterfall), the pace can be abysmal as hard deadlines approach and extra necessary work was not accounted for or addressed. This forces teams to work overtime to meet demands, and typically leads to burnout and turnover. XP's practice of a sustainable pace was created to allow developers to keep producing quality products without burnout.

Sommerville states that the practice of sustainable pace is nice on paper, but most of the time it's tough to convince managers to adjust expectations. In my experience if this happens there could be a breakdown of communication happening between the team and management. Senior members should communicate during reviews and even daily standups to address any roadblocks to development and release.

Sustainable pace is attainable if all team members truthfully work hard (during work hours) and communicate issues early to allow managers to adjust and compromise expectations throughout the sprint. Honest and thoughtful communication are key components to the Agile process, and the sprint reviews should show if the pace needs to be adjusted to maximize efficiency while avoiding burnout.

Pair programming

Pair programming is when two developers work together to work on a feature or knowledge share to get both developers on the same page. Typically one developer will "drive" the code development, while the other observes and offers suggestions throughout. This is even easier now than ever with the co-development tools available.

Sommerville mentions there isn't much evidence to suggest that pair programming is worth it, and that managers generally don't like the idea of two workers working on the same thing. Sommerville's take on this seems a bit rigit. I think that if used for the right circumstances pair programming can be valuable to team growth.

Pair programming is great for knowledge sharing within and between teams. There are many setups for pair programming, one being a senior member showing a more junior member how to do something, or a specialist helping to describe a solution to a general team member, or just one developer who "gets" the work showing another developer how. I've had many eureka moments doing pair programming, and the knowledge gained is invaluable.

That said, not every project needs to be paired, nor does the entirety of the feature development. It should be a tool to help a developer get past a road block and allow the team to fulfill the sprint goal.

Collective ownership

It's amazing how this practice came to influence how we share source code in open source. It's a great concept whether within the team, an organization, or the open source community to allow more eyes on the code that in turn can help resolve issues or suggest code improvements.

Sommerville mentions that this practice doesn't work for many developers as they may not want to share completed work. I can understand this as success metrics are necessary for individual growth within the company, but with modern code tracking its pretty simple to track via code blame.

For me, collective ownership is a good thing as long as organizations track and recognize contributions of individuals as well as teams. I think for many organizations they should close source their code from the public, but leave it open to those within the organization to allow a greater understanding of the code. Code sharing and company wide code style guides can help streamline development.

Conclusion

The creators of Extreme Programming believed that these practices were conceived as being holistic and essential. In an ideal situation they should be, and even if an organization or team may sometimes sway away from these ideals, they can always fall back on them throughout the sprint cycle.

Sommerville concludes in mentioning that developers aren't managers, and that business needs can't be left to developers. I agree, but the opposite should be true as well. XP and other agile methodologies seek to give software engineers and the greater team a framework to present technical hurdles to stakeholders, while remaining professional and flexible throughout the process.

-Patrick