Extreme Programming 1 (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 2

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.

Pair Programming3

Pair Programming is the process of having two programmers work on the same computer at the same time. Typically one of the programmers is ‘driving’ (i.e. typing and deciding what code gets typed in) while the other ‘navigates’.

The navigator doesn’t focus on tactical errors that the driver might make. Instead, they think about the context that they are working in. They ask questions like: ‘How does this new code fit in with the existing code?’ and ‘Is there a way we could change the code we just finished to make it simpler or better?’

The quality and simplicity of the code that two programmers create is usually far beyond what they would create separately because they are many fewer missed opportunities to improve the code. “Two heads are better than one” leads to much higher quality code. This higher quality code is easier and safer to change than code written by only one member of the pair.

Game programmers are almost always making small design decisions. These decisions can lead to the game being much more (or less) fun. Having two creative people brainstorming for a few minutes can lead to exceptional results. Pairing encourages these quick discussions without the overhead of gathering people for a big meeting or interrupting anyone.

Pairing helps build solid and happy teams by forming bonds of trust through shared experiences, lots of personal interaction, and the reduced frustration from not getting stuck as often.

Continuous Design4

Continuous Design is the art of keeping the software design in tune with what the program needs to do today. This means that you don’t build the generalized system until the program needs the generality, but you do ensure that your design for the simpler version of the system is well designed. Writing less code does not imply taking shortcuts or hacking; it only means that you should implement only what you need because it is easier to change the direction of a code-base when there is less code.

Part of the Continuous Design process is refactoring, which is changing code to make it healthier without changing any of its features. As you understand your design better or as the simpler design doesn’t suit the growing needs of the software, you often find that the program would be healthier or simpler if the code looked different. Refactoring is how we keep the code flexible.

Continuous design leads to simpler code. Simpler code is easier to understand and less frustrating. This helps people feel competent, confident and safe, all of which leads to a happy and energized team.

Real Customer Involvement5

In simplest terms, Real Customer Involvement is having real users play the game as early as possible. Since the team has been focusing on visible results this should be very early in the development cycle. This helps the team prioritize features and make better guesses in the future.

Another version of this is having the designer work extremely closely with programmers while the features are being implemented. This focuses programming effort where it will do the most good, gets the best trade-offs made and lets the designer say “That is good enough for now.” When programmers are focusing on providing visible results quickly and the designers can provide useful feedback about what is fun and what isn’t they can find the fun together.

Working with someone to get the result that works best for them makes both the client and the developer happy. This cooperative approach to implementing features also builds strong bonds of trust which is always good for a team.

Energized Work6

Energized Work, also known as Sustainable Pace or 40 Hour Work-Week, is the practice of only working as many hours as you are being productive. Working when you are tired or ill leads to slow work, many mistakes, unhappiness, and longer periods of tiredness or illness.

Because programming is fundamentally about ideas, programmers can make lots of progress in a short amount of time if they can come up with the right ideas at the right time. But coming up with these ideas is the hard part; our brains need to be operating at 100% or they are not likely to deliver their best solutions. Energized work keeps our brains healthy and happy so they can more often do the work that we need them to do.

Energized work helps support all of the other XP practices and keeps programmers doing their best work which yields better code and a more fun game.

Conclusion

As I stated at the beginning of this article, 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.

The power of XP methodology is that it allows game developers to reliably make great games while meeting the diverse needs of the various stakeholders involved in the development process:

In the end, it makes sense that that everyone can win using XP because we all want the same thing, “to make great games.”

Learning More About XP

These practices, along with the other XP practices: Whole Team, Planning Game, Small Releases, Customer Tests, Continuous Integration, Collective Code Ownership, Coding Standard and Metaphor, allow a team to rapidly deliver visible results. There are many excellent resources you can utilize if you want to learn more about XP or any of its practices. Kent Beck’s book, Extreme Programming Explained, is generally regarded as the best introduction to XP and I also recommend these web sites:

³ Williams, Laurie and Kessler, Robert. Pair Programming Illuminated. Boston: Addison-Wesley, 2003.

⁴ Shore, Jim. Continuous Design. IEEE Software, vol. 21, no.1, pp. 20-22, Jan/Feb, 2004. Online < http://www.martinfowler.com/ieeeSoftware/continuousDesign.pdf >

⁵ Beck, Kent. Extreme Programming Explained, Embrace Change, Second Edition. Boston: Addison-Wesley, 2004. pp. 61-62

⁶ Beck, Kent. Extreme Programming Explained, Embrace Change, Second Edition. Boston: Addison-Wesley, 2004. pp. 41-42