Embracing Fun: Why Extreme Programming is Great for Game Development
 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:
Management is happy because team morale is higher, the game can change to meet new business requirements, and visible progress and feedback let them know that the team is on track to hit their milestones.
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:
3 Williams, Laurie and Kessler, Robert. Pair Programming Illuminated. Boston: Addison-Wesley, 2003.
4 Shore, Jim. Continuous Design. IEEE Software, vol. 21, no.1, pp. 20-22, Jan/Feb, 2004. Online < http://www.martinfowler.com/ieeeSoftware/continuousDesign.pdf >
5 Beck, Kent. Extreme Programming Explained, Embrace Change, Second Edition. Boston: Addison-Wesley, 2004. pp. 61-62
6 Beck, Kent. Extreme Programming Explained, Embrace Change, Second Edition. Boston: Addison-Wesley, 2004. pp. 41-42
|
|
|
|
|
Previous