Extreme Programming ¹ (XP) is an Agile Software Development Methodology that focuses on adapting to change instead of predicting it. The power of XP methodology is that it allows game developers to reliably make great games while meeting the diverse (and often competing) needs of publishers, management and the developers themselves.

Conventional wisdom tells us that doing more for one of these groups will take away from the others. XP challenges this conventional wisdom and enables the development team to deliver high quality results that meet the needs of all stakeholders.

XP more reliably yields great products because of its focus on rapid releases of working software. Rapid releases of working software means that the game designer can see what the highest priority features look like without having to wait for very large systems to be implemented. This allows the designer to find fun gameplay more easily and “steer” the game towards the most fun features as quickly as possible.

So XP encourages the designer to steer the game during development and make more changes to the game design? This is exactly what most programmers don’t want to hear! If your software is difficult and painful to change, then rapid steering is the last thing you want. But the reality is that in order to find the fun gameplay, the designer is going to want to change direction as she learns more about how the game actually works. If the programmer’s job is to make a great game then we need to do our best to allow as much steering as we can. Extreme Programming practices focus development energy into delivering results quickly and keeping the project flexible.

This sounds great in theory, but you’re probably now wondering what exactly does XP do that allows for a project that is easy to steer? It uses mutually reinforcing practices that keep the code as simple and healthy as possible. In short, XP requires that the team prioritizes the features, works on them in order, only writes code that is needed for implemented features, and continually applies small design improvements to keep the code healthy.

The remainder of this article provides an overview of five key XP practices including Test Driven Development, Pair Programming, Continuous Design, Real Customer Involvement and Energized Work. These practices, along with other XP practices not included here, allow a team to rapidly deliver visible results. The visible results inform the designer who can then steer the game in a positive direction. Because the programmers have been keeping the code flexible, making this code do something new is comparatively easy which leads to the next cycle of visible results.

As you review these practices it is important to remember that XP is not about automated unit-tests, a 40-hour work week, nor is it about pair programming. While most good XP teams do all of those things, they are simply the means to the end of delivering a great product. This is what XP is about – delivering great games.

Test Driven Development ²

When practicing Test Driven Development (TDD), programmers write a small piece of code that describes how they want a new feature in the program to function. This piece of code is called a “unit test” and it initially fails because the feature the test describes has not been implemented yet. The programmer knows that she is done with that feature once the test passes. This process has a number of benefits, but automated unit testing is the most visible one.

Automated Unit Tests are tests that show that each piece of the software does what the programmer thinks it does. Developers can easily run these tests to validate that any changes they have made did not break already implemented features. These tests allow them to rapidly and safely make changes to the project.

Regression is one of the most insidious forms of friction that a development team encounters. Early in the project there are only a few features that need to continue to work, but as the team makes progress and the project grows, there often become so many features that it is nearly impossible to keep them all working at the same time (or even know which ones are working). Automated tests give us a framework that scales with the number of features we have, thus allowing us to implement new features without worrying about hidden regression.

Another benefit of TDD is that it helps the programming team feel happy and energized by constantly rewarding them with lots of little successes, through passing tests, as they move closer to the bigger success of a working feature.

¹ Beck, Kent. Extreme Programming Explained, Embrace Change, Second Edition. Boston: Addison-Wesley, 2004.

² Beck, Kent. Test-Driven Development by Example. Boston: Addison-Wesley, 2003.