Reflecting on Extreme Programming(XP)

• Introduction
• XP Practices
• What I liked the most
• What I liked the least
• Conclusion

Agile software development is an umbrella term used to describe a set of methods and practices based on certain values and principles. These values and principles are based on the Agile manifesto which came about as a consequence of industry frustration with software development projects in the 1990s. A lot of projects were being cancelled due to the vast time lag between business requirements and the delivery of the product that answered those needs. The Agile manifesto and its principles birthed a number of frameworks to help teams organise the way in which they build software products.

The most popular being:

1. Scrum
2. eXtreme Programming (XP)
3. Feature Driven Development (FDD)
4. Lean Software Development (LSD)
5. The Crystal Method
6. Rapid Application Development (RAD)

Introduction

This article will focus on XP programming, which will be a review of the book I read: Extreme Programming Explained: Embrace Change by Kent Beck, Cynthia Andres. Software engineer Kent Beck developed XP in 1996 and it has since grown to be one of the most popular agile frameworks.

This is a fundamentally important book on how software should be delivered. In this book Kent focuses on values, principles, and practices of XP programming. His values and principles are centred around recognizing the humanity of the programmer and reminds us that software is written by people and XP brings back humanity to those who practice it. This is through recognizing that these engineers/developers have an agency over their work and the processes they are involved in. Principles act like a bridge, connecting values and practices, without the XP principles you wouldn't know how to apply your values to practice.

Agile methodologies may evolve with time, but the practices being adopted will lie on a firm foundation of the values that Kent described, namely:

• Communication
• Simplicity
• Feedback
• Courage

XP Practices

Practices by themselves are meaningless unless given a purpose by values. The practices he states are situation dependent, and thus should be applied by teams as they see fit. The intention is to provide you with clear goals and give practical guidelines on how to get there. Some of my key takeaways from the practices he recommends are the following:

1. Work Cycles - Teams should have brief meetings at the beginning of each week to review their progress to date and plan work for the week. He recommends weekly cycles because they are more focused and deliberate about what is to be achieved. Reflection is an important aspect of growth, each end of the cycle should be an opportunity to reflect on the project, on what went well and if the task being worked on still aligns with the larger goals.

2. Testing - This is an important component in software development. Testing gives the engineers the confidence that the code they have written works as expected. When tests are written and what types of tests are written can be determined by the engineer as long as testing is embraced and teams need to be disciplined enough to continuously write them.

3. Pair Programming - This is a technique where two developers work together at one workstation, one writes the code (the driver) whilst the other observes each line of code being written. Pair programmers brainstorm refinements to the system, share ideas and help each other when one one is stuck and most importantly they hold each other to the team's agreed practices.

4. Small releases - XP encourages small releases in order to receive feedback as often as possible. The feedback can come in at two levels, at the lowest level you ensure that the code written works as expected and at the highest level you get feedback from the customer to be certain that what you built is what the customer expects and functions correctly. Kent also advocates the practice of continuous integration i.e. making many small deployments instead of one big deployment.

5. The Planning Game: The idea that software is produced in short increments from a prioritised list of work items.

6. 40 Hour week: I believe that working overtime continuously is not good for anyone who wants to be effective, excellent in their work and avoid burnout. Kent also emphasises the importance of sticking to a 40 hour week so the team finds time to rest and focus on other non-work related activities. The moment your team works overtime the second week in a row, it smells like trouble, the team is failing somewhere.

What I liked the most

I agree strongly with most of his principles and practices, such as the fact that software development is ultimately about constant change, that communication is a crucial part to the whole process. Effective communication ensures that everyone has context and everyone's voice is heard. When the different team members i.e. Testers, architects, project managers, technical writers and engineers are walking abreast, they make more progress than if any group tried to be more dominant so others follow. He also emphasizes the need for teams to change their approach to work and strive to embrace change instead of trying to predict everything in detail or trying to predict what is not predictable so as to avoid unnecessary frustrations.

What I like most about the book is that it levels out the landscape, instead of being lost in the system of hierarchies and bureaucracies, XP brings responsibility to everyone in the team. One profound point he highlights is that a career in software should be one of continual development of one's skill and not race towards being at the top. He touches on shared responsibility, lean production techniques and continual improvement as ways of being successful in the software business. In addition this practice ensures that teams take on a portion of work they can finish in time whilst working at a sustainable pace. The likely results from following these practices are: substantially reduced software defects, improved code quality, a motivated team, reduced development time and a productive team.

What I liked the least

My one concern with his book is that there are moments where he lacks concrete practical examples when he writes on some concepts such as design. I felt the ideas he tried to present were quite high-level and vague and I had a difficult time trying to translate or relate them to real projects I work on and how they can be applied. There are moments where he also seems to be very opinionated on certain issues, somehow suggestive of his certainty that certain methods will never work in any type of team.

Conclusion

Overall, this is a great book that has had a huge impact in the software development industry. This can be seen through a number of teams that have adopted its practices such as Test Driven Development, refactoring, pair programming, Continuous Integration (CI), Continuous Deployment (CD) which have become common terms too. I would recommend anyone who works in the software engineering space find time to read this amazing book.

References

1. Extreme Programming Explained: Embrace Change, By Kent Beck with Cynthia Andres