(above) Nothing to do with Extreme Programming
Extreme Programming – the name itself conjures up all sorts of images like the one above. It gives the impression that it’s some sort of high-octane, living-on-the-edge way to develop software. “I’m not extreme, that’s not for me” – I think the name puts a lot of developers off from the very start.
But the thing about Extreme Programming (XP) is that it’s neither extreme or just about programming! Taken as a whole, XP is a collection of values, principles and practices to develop software – it is a methodology in it’s own right. At the core is the distinction between doing Agile and being Agile – these are the values and principles, and if you skip these and head straight to the practices then you’re missing the point. These pre-date the Agile manifesto and Kent Beck’s influence on it is clear to see.
Then there are the practices - 12 things you can actually do. Only a handful of these are actually related to programming and none of them are extreme, although they work best as complementary practices. Because a lot of XP’s non-programming principles & practices (e.g assume simplicity & embracing change) have been adopted by other methodologies, XP’s technical practices can be used effectively to develop software on an Agile project. In fact, you’re limiting your ability to be Agile if you don’t use these techniques.
But just because XP isn’t actually extreme, it doesn’t mean it’s easy. Practices such as Test-driven development (TDD), pair programming and simple design are straightforward to understand but hard to do and maintain.
People tend to look at the short-term impact of the techniques:
- TDD – it takes too long, we can test later
- Pair programming – a waste of resources
- Simple design – I know I’ll need this feature later so I’ll add it in now.
All too often teams will skip these practices because of the perceived negatives or a lack of buy-in to the values and principles.
Instead, teams should focus on the longer-term gains:
- TDD – a lean codebase of emerged design, with tests that act as both safety nets and documentation
- Pair programming – a near instant feedback mechanism and a great way of spreading knowledge
- Simple design – focus on the immediate features to enable us to release value early. We’ll worry about the other stuff when we actually need it.
Sure, for a team of people used to just coding in isolation, this will be a big change, but the benefits should start coming through quickly. Don’t forget that nothing worth doing is ever easy and a good technical coach can really help at this point.
You’ll learn more by doing than by reading, but Kent Beck’s “Extreme Programming Explained: Embrace Change – 2nd Edition” is a great place to start. Once you’ve understood why you’d want to develop software this way, just pick a technique and try it out. Once you’re comfortable with that technique, pick another.
Don’t be put off by the name - there’s no need to get your skateboard out of the loft if you want to try Extreme Programming!
Want to get more familiar with Extreme Programming?
Check out our Certified Scrum Developer Courses