Extreme Programming as a holistic practice relates to project management and programming practices to deliver and implement changes to software confidently and reliably. As I’ve grown as an Agile and XP developer, I’ve focused more and more on the core XP development practices [Test Driven Development (TDD), Pair Programming, Continuous Integration (CI), and Refactoring] and firmly believe that the programming practices do not require the Agile project management framework. Without a doubt, they have a mutual relationship and they can both stand on their own and help organizations to deliver software separately. For the sake of this discussion: when I talk about what I consider the core XP Development Practices, I am talking directly about TDD, Pair Programming, CI, and Refactoring, and not the project management methodologies.
The type of software produced using XP practices tends to be of high quality (low defects), maintainable, functional, and robust. Teams following these practices also write highly cohesive and loosely coupled code. Using patterns like Dependency Injection, having multiple layers of supporting tests (Unit, Integration, Functional, and System tests), and intentional programming techniques yield very SOLID code that supports continuous improvement and ruthless refactoring. The benefits of a code ecosystem like this is that feedback loops are short, there is a safe coding environment (supported by tests) facilitating change, and a culture of communication and support thrives. Environments like that encourage innovation and taking the time to do the right thing.
It’s important to note that developers and teams that adopt these practices do not write bug-free code. Rather, the code written by XP teams tends to contain fewer defects than code written without the practices. Because of the XP practices, the code is in a much better state to fix defects because of the automated testing feedback. The XP “Find a bug, write a test” mindset ensures that regression is avoided and continuous improvement of the codebase is fostered. Same goes for when re-work happens — the supporting tests and continuous integration environment shorten feedback, so that when something goes wrong it’s known quickly and can be fixed or adjusted.
As my skills as a developer have evolved and I’ve learned how to write better code, I’ve found myself embracing the XP practices more and more. At no time in my career have I spent less time debugging/tracing/fixing defects, and more time just writing new code. All the time that I used to spend stepping through code and verifying functionality is now done in an automated fashion with unit/integration/functional tests. Not needing to track every nuance and functional caveat — because they are tracked and verified by tests — and just being able to write code is invigorating.
Case in point: I recently inherited a codebase from a senior XP developer co-worker, who I’d worked with before, that I was supposed to maintain in a more traditional Waterfall project environment. It wasn’t a huge project, ~200,000 lines of code across ~200 files, with ~80% test coverage. I got about half a day’s knowledge transfer from him, essentially how to setup and run the project. Because of the tests and the XP Practices, I felt very confident jumping in and fixing defects one day and removing ~1000 lines of code with a Builder Pattern refactor to some duplicated fundamental architectural code. I do not believe that I could have done such work had it not been for these XP development practices. I also know that the project management style had zero impact on the efficiency and the resulting quality of these changes.
In 1999, Kent Beck gave us Extreme Programming Explained, which outlined a brave new world. I believe that developers can get a lot of benefit from using the core XP development practices. Developers will write better and more SOLID code. Defects will be fewer and easier to find with minimal regression. A wide range of tests weave a safety net throughout the code that enables and supports code reuse, refactoring, and continuous improvement. These practices will help developers discover that they have more time to write new code because they are not debugging and stepping through as much code to verify changes, regardless of how their company delivers products. Exciting techniques that can help developers of all skill levels and project management styles, I say.