Extreme Programming
Extreme Programming sounds pretty exciting. But how do you take the relatively mundane task of typing code into a computer, and turn it into something extreme? Figure 3, below, may appear to feature a great example of Extreme Programming. However, it is lacking one of the most important fundamental attribute of Extreme Programming- a second person.
Figure 3:
Extreme Programming was developed with four basic values:
- Communication
- Simplicity
- Feedback, and
- Courage (Siau, 2007).
Further, there are also four basic activities:
- Coding
- Testing
- Listening, and
- Debugging (Siau, 2007).
Finally, Extreme Programming ecompasses twelve core practices:
- Planning game
- Small releases
- Metaphor
- Simple design
- Test
- Refactoring
- Pair programming
- Continuous integration
- Collective ownership
- On-site customer
- Coding stanards, and
- 40-hour work week (Francisco, Holcombe, Gheorghe, 2003).
The basic concept of Extreme Programming (XP), is to embrace change. As such, practitioners immediately code what the customer specifies, and then the code is driven through customer-designed tests to verify that the code meets the customers needs. Requirements determination takes a back seat, as additional requirements can always be added at a later point in time. While this allows for a quick turn-around time, the risk to developers is that customers will see requirements as dynamic and be more likely to request additional changes (Siau, 2007).
Extreme Programming involves strong collaboration between managers, developers and customers. XP practices concentrate on people rather than processes, and they are heavily based on good, frequent communication. Team members need to be responsible, skilled, social, and above all communicative to be successful (Sfetsos, Angelis, Stemelos, 2006).
The Planning Game begins the XP process with user stories- a substitute for the traditional large list of requirements, initial project planning, and division into iterations. Program tests are written before the code, making it faster and easier to write the code to specifications. Next, code is written using the Pair Programming method, whereby two programmers work on each section of code (Sfetsos, et al, 2006; The Rules of Extreme Programming, 1999). I would like to go into further detail regarding Pair Programming, since it is such an important aspect of Extreme Programming.
Pair Programming takes a task which is traditionally solitary and turns it into a team effort. The task consists of the driver, who sits at the computer entering code, and the navigator, who sits next to the driver, offering advice and assisting with decisions. The programmers switch roles regularly, although there is no set time interval between switches. Reported benefits of Pair Programming include improved product quality, improved developer morale and job satisfaction, fewer coding errors, and improved mentoring and training (Hanks, 2008; Drobka, Noftz, Raghu, 2004).
The Refactoring process removes duplication and unneeded functions, and reworks obsolete designs. Simple Design is a philosophy by which simplicity always wins out over complexity. With Common Code Ownership, every team member has the right to change any line of code anywhere in the program, not just the section that he or she is working on. Continuous Integration encourages programmers to send code updates out in a short time frame- no more than a day- so that team members don't start following divergent paths.
The customer must be always available, preferably on-site, to facilitate easy communication and involve the customer in the process. Short Release Cycles insure that deliverables are created often, and the customer can easily tell what changes are necessary. Please see Figure 4 for an example of Extreme Programming cycles. The Forty Hour Week is introduced to encourage developers to work hard for forty hours per week, with the incentive that they can relax during their downtime, coming back in refreshed and ready to tackle the next day. This is a departure from the traditionally long weeks worked by developers.
Consistent Coding Standards ensure that all team members can read and refactor code easily, encouraging collective ownership. Finally, a Metaphor is a simple definition of the project, useful for bringing new people in without overwhelming them with a book of project information and documentation. Furthermore, the Metaphor ensures that class and method naming stays consistent throughout (Sfetsos, et al, 2006; Extreme Programming, 1999).
Figure 4.
For additional information on Extreme Programming, please see extremeprogramming.org.