Extreme Programming within the gaming industry!
Extreme Programming vs. Kanban and SCRUM
Extreme programming cannot really be compared to KanBan or SCRUM. Extreme programming, also known as XP, is a methodology all on it’s own. As the name suggest, XP takes some of the fundamental and basic things that work well, and put these to the extreme. Let’s take feedback for instance; it’s always nice to get good and constructive feedback as often as possible, XP says the following: “Best practice is to have a customer sitting in the same room as the development team during the entire process”. What exactly is meant by this? Let’s talk XP!
What is Extreme Programming?
As mentioned above, XP takes the fundamental things to the extreme, just like the example I gave you. Another example could be testing the code. This is where Test Driven Development (TDD) gets into the picture.
Test Driven Development
The name itself suggest what is meant by this. Test driven means that you write your test FIRST, and then the minimum code that would get through this test, then rewrite the test, and rewrite the code. Here’s a simple step-by-step TDD guide:
- Write the minimum amount of test code possible
- Write the minimum amount of code possible to pass the test
- Expand the test code to slowly achieve the functionality you’re looking for (DO NOT write the entire test code here, but go SLOW)
- Expand the code further, but still the minimum amount to pass the test
- Expand the test code further
- Keep doing this untill the functionality is complete
- Refactor the code
Wild word appears! Refactoring?
Refactoring means the following; go back to the code you just wrote and optimize the f*** out of it! Make it fast, make the code short, cut some lines from the code. Basically; refactoring = CLEAN UP!
Of course you can’t get away with the planning!
In the very beginning of the project, the user stories are printed/written down on physical cards. This is basically the Release Planning phase.
Before every iteration, you move these cards around until you find a point where you can say; “We can finish these task and make the first (or next) release!”. This is called the Iteration Planning, and this is done before every iteration. An iteration can last for as long as you decide, but normally they last around 2-3 weeks. They could in theory last 2-3 years depending on the size of the project. This is 100% up to you.
When developing within XP, to keep the plan realistic, we have 4 variables in play; scope, resources, time, and quality. These 4 variables needs to walk hand in hand. Imagine that you don’t have enough time, this will effect everything else; you can’t implement the entire scope (scope), the quality may not be as expected (quality), and you may not have enough people working on this (resources).
Let’s take another example to make sure it’s understandable. Imagine that you don’t have enough people working on the project (resources); suddenly you won’t have enough time to finish everything (time), the quality won’t be as good as possible as you need to work faster (quality), and maybe you need to shorten the scope if you wish to finish on time (scope).
XP tellsu s that the development team needs to work in an open space. Everyone should have their voice heard, and everyone should be able to get help. Placing whitebaords around for sketches is a great idea, so the team can quickly draw a sketch and explain to others. Make sure to have a larger area ready for the daily stand-up meeting (mentioned this in the SCRUM post).
Moving people around is one of the better values from XP. In a development team you may have 1 person that knows everything there is to know about Unreal Engine 4 blueprints, and the rest of the team isn’t that strong, but they can get the job done. Moving people around makes sure to avoid these knowledge bottlenecks, as every member of the team moves from task to task, trying to solve it the best way they can and perhaps get some help from that 1 brilliant human being!
Nr. #1 rule of XP: Fix XP when it breaks! Nuff’ said!
Make sure to have as simple a design as possible. A simple design takes much less time to finish than an advanced design, and everyone in the development team can easier understand what is going on. Don’t go around using Singleton pattern if this isn’t necessary!
XP has a feature called Spiking. This feature is basically what modern people would call; researching. You know the times when you sit within Unreal Engine 4 are you’re about to develop an inventory system (Yuck!) and you’re completely clueless? XP has an answer for that; spiking! Keep searching the internet for solutions, ideas, possible plugins?
Last but not least; refactor as I mentioned earlier in this post.
In order to get the best out of the project, make sure to ALWAYS have a customer nearby. In game industry, this would most likely be your chief of development (if you’re making blueprints/writing C++). XP requires constant feedback, and help ASAP in order to work properly. Nothing is worse than sitting 1½ hour just waiting for help!
The code has to be written in standard that the team has agreed on. This can be the following:
- Make sure to add documentation on a function
- Make sure to align the connections properly using reroute nodes (blueprints)
- The prefix of blueprints should always be _BP
These are just a few ideas to what I mean. Go ahead and come up with some yourself and put them in the comment section below the post!
Code the unit tests first aka. test driven development as mentioned earlier in this post!
All production code is pair programmed. Now what exactly is Pair Programming? Pair programming means that you are two programmers sitting side by side at a single PC, working on the same task. We have a driver; the person actually writing the code, and we have the navigator; the person sitting next to the driver watching him code.
- The driver: the man behind the code. This person should just write the code as if no one was next to him. If he encounters a problem, the navigator and the driver should together discuss the situation until they find a solution.
- The navigator: the person next to the driver. This person should bring relevant ideas to changes in the code that could either make the system faster, better or shorter in lines. This person should bring inputs to the drivers head about solutions.
When using pair programming, it’s important to change roles sometimes. This could be every ½ hour, every hour, or every 2 hour. This is up to you, but make sure you change roles several times during a working day.
Usually many people are members of a development team (take for instance Blizzard, Bethesda, EA, etc.). When a team reaches these sizes, it’s important that only 1 pair (pair programming pair) integrates at the time. And make sure to integrate often!
To integrate, you can use a dedicated integration computer. This is called Continuous Integration. This is not something I’m going to cover within this post. If you wish to know more about continuous integration (CI), please post a comment below, or search the internet.
As mentioned many times now, the tests should be written first, and it’s extremely important that all code passes these tests before it can be released! Should a bug be found, make sure to create a test that catches this, and then solve the bug.
Welcome to a world of SCRUM, KanBan, XP and Agile development!
By reading this post together with the first two, you should have a basic understanding of how the agile development methodologies work. I hope you learned something new by reading the posts in the series. If you have any questions regarding the processes, please don’t hesitate to write me a comment below! Is there anything else you wish to know, please comment aswell!
It’s been a pleasure to write this series, and I hope that some of you might use these methodologies in your projects!
Happy coding, and until next time!