Extreme Programming

For those of you following, I have been delving into more & more practices and thought I would look into Extreme Programming (XP), created by Kent Beck (one of the original authors of the agile manifesto). Some of you (like me) may feel that the term "extreme" may be a bit overused (do our developers have to do barrel-rolls while coding at their desks?) All kidding aside, my interest in Agile development (especially Agile game development) is currently peaked and I will continue to delve into more an more aspects of it.

I decided to pick up Sams Teach Yourself Extreme Programming in 24 Hours by Stewart Baird as I had never really picked up a book that mentioned learning something so quickly (I remember the old programming post Teach Yourself Programming in 10 years by Peter Norvig :P). Nevertheless, I always feel it is important to start somewhere, and a book like Baird's gives a distilled view and framework to graft a suitable framework for extreme programming in a very concise and organized manner.

Baird's book, breaks down the XP aspects into twenty-four, "one-hour" chapters, each dealing with a different aspect of XP. There were a few chapters that were either Java or .NET based (especially related to Unit testing), so the relevance on those may vary depending on your interest, but the underlying principles are still important. But, of course the question "what makes it "EXTREME" Programming"? XP like many Agile methodologies focuses on "simplicity, communication, feedback and courage" (I feel like "planning" would also be important to add in the list, but XP focuses more on the developer than the leader/manager). XP has a lot of similarities to other agile requirements, but handles them in a slightly different manner, the most obvious being the focus on pair-programming.

The argument for pair-programming is the focus on quality, by having two sets of eyes on code as it is being written, the developers will end up with constant feedback, improved code quality and less bugs and design flaws. In Hour 11, Baird mentions the time lost upfront will be improved later as less bugs will be found and have to be fixed, thus actually saving development/bug fixing time. The trade-off being 15% slower dev times (to use pairs), but 15% less defects. Baird gives an example of how this will save time:

50,000 lines of code takes 1 individual 1000 hours (at 50 lines per hour).
50,000 lines of code takes a pair 1150 hours (at 50 lines per hour). 15% more time.

Baird uses Watts Humphrey's A Discipline for Software Engineering that 100 defects occur for every 1000 lines of code, but estimates that 30% could still remain after some software development "rigor" has been put forward, meaning 1500 defects in 50,000 lines of code. Baird mentions the total time could be 10 hours per defect to find and fix each one of them.

15,000 hours spent finding the 1500 defects from an individual developer.
12,750 hours spent finding the 1275 defects from a pair of developers. (15% less defects)
= A saving of 2,250 hours.

While I encourage the devs on my team to work together as much as possible, I am not as sure about implementing pair-programming. In my opinion, the most useful situations for pair programming would be when there is a lack of design, research is required in solving the problem, a lack of motivation from one of more developers or a real need for information sharing on a certain section of code. If the design is already in place and knows the path to take I would be less inclined to use pair-programming in those cases.

I will keep some of the extreme programming ideas in my back pocket and will think about them. I prefer the scrum approach for organizing, but do like some aspects of the book (including some benefits of pair-programming). For me simplicity is one of the best focuses, and in a professional work environment it is important to focus on YAGNI (You Ain't Gonna Need It) to prevent over-engineering (although I would encourage those interested in this type of engineering to experiment on their own home projects). I also like the idea of collective ownership of the code and of course the 40 hour work week (which is especially hard in games, as there are a lot more iterations than there are in other requirements (like instrumentation logic, or security systems, and I imagine some applications and systems too)).

I will continue investigating Agile methodologies as well as mention some of the "extreme" ideas to see if any of the other leads are interested in exploring these ideas. I would be curious to see how they work with the company, but think I may shelf them for the immediate future.

Until next time, I remain,
Michael Hubbard
http://michaelhubbard.ca

P.S. I am following up on the Extreme Programming RoadMap and will see if I can find much in the way of Extreme Game Dev (although I still think it may be hard to top Keith's Agile Game Development with Scrum (previous post)).