Introducing XP

XP is a lightweight, agile process whose creation is attributed to Kent Beck, Ward Cunningham, and Ron Jefferies. XP was first put into practice back in 1996 by Kent Beck, who applied the process on the now famous C3 project at DaimlerChrysler. The process personifies the current crop of agile methods and targets small to medium projects with vague or rapidly changing requirements.

XP has created a huge buzz within the software development community, and much discussion still rages about the true benefits of its ultra-lightweight approach to development. Unlike most methodologies that stress the importance of upfront design and meticulous documentation, XP throws away the old rulebook and instead concentrates on the act of coding rather than documenting.

This standpoint has made the process immensely popular with hardcore developers, who have welcomed XP with open arms. To most software engineers, it was as if someone had announced that cigarettes, chocolate, and alcohol were all good for your health.

Unfortunately, the minimalist approach of XP has been interpreted by some engineers as being an excuse to discard many of the disciplines of software development and jump straight into the activity of coding. As we shall discover, this is not the intent of XP, and instead the method promotes a deliberate and highly disciplined approach to software development. Arguably, XP requires more discipline than RUP, which gives the engineer the option to omit many parts of the process. Instead, XP demands that you embrace all of its practices.

The XP Practices

Extreme Programming Practices

• Planning game

• Small releases

• Metaphor

• Simple design

• Testing

• Refactoring

• Pair programming

• Collective ownership

• Continuous integration

• Forty-hour week

• Onsite customer

• Coding standards

The RUP framework comes with an abundance of disciplines, activities, artifacts, and roles, any of which you may choose to incorporate in your project. XP is more concise and is essentially comprised of 12 basic practices, each of which you must follow in order to exploit the full benefits of the process.

These practices, or rules, of XP align with the key activities of planning, designing, coding, and testing. Each practice is undertaken in accordance with the XP values of simplicity, communication, feedback, and courage, which permeate the entire process.

Let's begin with the 12 practices that make up XP:

Planning game.

Plan regularly and involve all members of the team in the planning activity, including the customer. Plans are devised based on business priorities supplied by the customer and technical estimates from the development team.

Small releases.

In line with the value of simplicity, first put a simple system quickly into production, and then release new versions over a number of short iterations.

Metaphor.

Have a simple shared story of how the system operates to guide all development effort.

Simple design.

Keep the design simple and avoid designing for unspecified requirements. Refactor out complexity as soon as it is discovered.

Testing.

Write unit tests continually and ensure they execute flawlessly. Automated unit tests are written ahead of the implementation of a class. Suspend development until a failed test has been rectified. Customers write tests to validate new features.

Refactoring.

Developers continually restructure the code base without changing its behavior to maintain simplicity, remove duplication, improve communication, and add flexibility.

Pair programming.

All production code is written by two developers working at a single machine.

Collective ownership.

Any developer can change any system code at any time.

Continuous integration.

Integrate all code as soon as any task is complete. Look to integrate all code several times a day.

Forty-hour week.

Stick to a 40-hour week. Never work overtime two weeks in a row.

Onsite customer.

Have an empowered representative from the customer working with the development team and available any time to answer questions or discuss requirements.

Coding standards.

All developers write code in accordance with a common set of coding standards, thereby emphasizing communication throughout the code base.

The 12 practices complement one another to the extent that to omit a single practice could cause the whole process to unravel. For example, simple design requires refactoring to remove unnecessary complexity; refactoring relies on the testing practice to guard against unintended changes in system behavior. XP therefore requires discipline from the team in ensuring all practices are employed on the project.

The practices of XP lay down the rules for how developers work on an XP project. To understand how an XP project is conducted, we need to look at the activities of XP.

Planning

Planning is a critical activity on any project, more so if the project is following an adaptive method. These methods require decisions on the direction of the project to be made at every step, and in close consultation with the customer, if the project is to be carefully steered toward a successful conclusion.

Planning on an XP project is a continuous activity driven by the feedback from both customers and developers. Like RUP, planning in XP occurs on two levels. The first level is the broad project plan, or release plan using XP terminology. This defines the overall structure for the project and gauges the number of iterations necessary to complete the system.

The second level of planning is the detailed iteration plan. This covers just a single iteration. Iterations in XP run for approximately two weeks, and the content of an iteration is decided upon based on the customer's prioritized requirements and estimates from the developers for each requirement. A release is made at the conclusion of an iteration, as dictated by the practice of small releases.

Throughout the iteration, teams should look to integrate their work on a regular basis, as specified by the continuous integration practice. This avoids the danger of costly integration problems caused by last-minute integration efforts.

XP iterations are timeboxed, so discussion is required with the customer to determine which requirements must be included within the allocated timeframe. The need to collaborate closely with the customer in all aspects of the project, including its planning, gives rise to the XP practice of having an onsite customer.

Where RUP iterations are driven by use cases, XP iterations are planned around user stories. The function of an XP user story is similar to that of a use case but is considerably simpler and shorter, usually running to just a few sentences. The iteration evolves the story, but the "written" story remains in its original terse form. Like use cases, user stories also drive other project tasks, with acceptance tests being written for the stories provided.

Acceptance testing is described in Chapter 15, Efficient Quality Assurance, along with tools for supporting the testing activity.

Figure 3-3 illustrates how user stories drive iterations within XP.

Figure 3-3. User stories and the XP iteration lifecycle.

In addition to release and iteration planning, XP teams look to hold short, standup meetings at the start of each day to lay out the tasks for the day, arrange pair-programming teams, and discuss any issues that may have arisen since the last meeting.

Designing

Design is one of the most contentious areas of XP, as according to the main practices, followers of XP do not appear to do any design work. In contrast, RUP capitalizes on its links with the UML and uses modeling as the main design activity.

XP has no place for models, stating only that design should be kept simple, as per the simple design practice. This is enforced by the refactoring practice, which looks to remove complexity at every opportunity. Furthermore, all members of the team should have a common understanding, or metaphor, as to what the system is and how it works.

As for formal design processes, the original C3 project used Class, Responsibilities, and Collaboration (CRC) cards for running design sessions, and this technique has proven popular with some XP teams.

Designing with CRC Cards

CRC cards offer a simple but effective approach to design that involves several people from the team. As XP encourages collaborative development, any method able to effectively engage a number of people in the design process is a good candidate for an XP project.

Start the design session by getting hold of a stack of blank cards. If you can't find any of these, the back of a business card will just about do, but you'll need to reduce the size of your handwriting.

Each card represents an object in the system. Write the name of the object at the top of the card, the responsibilities down the left-hand side, and the collaborating classes to the right of each responsibility.

The session starts with a particular functional scenario, or user story, and each member of the group holding a number of cards. The group talks through the scenario, with the conversation passing to the holder of the card whose class is responsible for that part of the story. The details on the cards change as a result of the discussion until a set of classes, responsibilities, and associated collaborations have been identified that will execute the required scenario.

In an XP CRC session, no formal design is produced, but the group takes away an understanding of how the system will implement the required functionality.

Coding

If the subject of design on XP projects is contentious, then the practice of pair programming, whereby two developers share a single machine, is positively explosive.

The arguments against pair programming are twofold. First, management becomes nervous about the productivity implications of having two developers constrained by the bottleneck of just one machine. Second, developers become almost territorial over a task they have taken responsibility for, and they have a tendency to feel threatened at the thought of having anyone closely scrutinizing their work. Frequently, developers cite the need for quiet time in order to fully focus on a problem, claiming the need to be "in the zone" in order to overcome technical development challenges.

Resistance to pair programming can be quite extreme, with developers vehemently denouncing the need for the practice. It is well worth reading the article The Case Against XP, by Matt Stephens, on the subject of pair programming and XP in general. This amusing article provides an opposing viewpoint to the practices of XP and can be found on the Software Reality site at http://www.softwarereality.com/lifecycle/xp.

If you have tried pair programming, you likely found it mentally exhausting. Having a second developer working with you on a piece of code seems to keep you constantly alert. Common distractions, such as getting up and making coffee or surfing the Web, get pushed to one side with a second pair of eyes on the screen. The excessive mental effort pair programming imposes is probably one of the reasons why XP recommends sticking to a 40-hour week.

The pair-programming practice came into being as an extreme reaction to code reviews. While they may sound like a good practice, code reviews, as they are commonly practiced, are a flawed quality-control process.

Code reviews are often left to the last minute on a project, by which time it is often too late to fix any of the problems identified by the review. Moreover, conducting a thorough review takes time, as the reviewer must form a clear understanding of the developer's intent and approach. Seldom is enough time set aside to conduct a proper review. Likewise, reviewers often have their own tasks to complete and so frequently fail to invest the necessary effort in the review process.

The XP solution to the problems surrounding code reviews is to have them occurring all the time. Pair programming achieves this, since the developer pair is continually checking the code against both the requirements and the project's coding standards. Mixing up pairs regularly ensures that no developer flaunts the project standards unnoticed. Furthermore, the practice also links in with collective ownership, as knowledge of the code is spread around the entire team.

Pair programming is making in-roads into mainstream development as more and more companies discover that two heads really are better than one. Some novel approaches are being formed that enable people to more easily work together in pairs. One group at HP undertook a distributed XP project and gave all developers hands-free headsets and desktop sharing software in order that team members could pair program remotely.

Pair programming does have its limitations and is not suitable for all programming tasks. A classic example is research or investigative work. Here, people really do need some quiet time to explore and read. However, if programmers are writing production code, then under XP rules, they should be doing so in pairs.

Testing

XP has single-handedly breathed new life into the concept of test-driven development, whereby tests are written ahead of any implementation.

Under XP, all classes in the project should have supporting unit tests. This practice enables refactoring of the code base without the danger of system behavior being impacted.

Unit tests also support the practice of collective ownership of the code. If a programming pair is changing code developed by other members of the team, the supporting unit tests will ensure they can do so without inadvertently destabilizing existing system behavior. The test suite should identify this situation if it occurs.

Upon identifying a defect, the programmer must write a unit test for the problem. This approach guards against the defect creeping back into the system.

The test-first development approach is examined further in Chapter 14, Test-Driven Development.

XP Roles

Agile methods have gone to great lengths to reaffirm the importance of the individual worker. Early methodologies looked to downplay the role of the individual, seeking to make software development a production-like process, with IT staff undertaking factory-type roles.

Job descriptions in XP are sparse compared to the comprehensive list included under RUP. Nevertheless, this serves to underline the importance of the individual on the project and the significant contribution he or she makes.

True to the nature of the profession, software engineers on an XP project must be multi-skilled. They are expected to take part in the planning, designing, coding, and testing of the system. Thus, XP breaks away from the standard convention of defining specific roles for architects, designers, managers, coders, testers, and the like. XP places greater emphasis on generalists rather than on specialists, so if you're working on an XP project, expect to get your hands dirty.

Unfortunately, J2EE developments often have a need for specialist skills due to the diverse range of Java-based technologies involved. It is not atypical to find developers who are expert in JSP but have never written an Enterprise JavaBean. Even fewer developers will have been near a J2EE Connector Architecture (JCA) adapter. This can be an issue, especially with the collective ownership practice. Attempting to get the entire development team through the learning curve associated with the intricacies of JCA technology in many cases just isn't practical. Pair programming is one way of spreading the knowledge, but on complex J2EE systems, it is hard to avoid the need for specialization in a particular J2EE technology. XP does advocate the consultant role, which can help in this area.

The following list provides a brief description of the roles for an XP project, as defined by Kent Beck:

Programmer

The programmer is a fully fledged software engineer and represents the heart of the process. The programmer is involved in almost every aspect of the development, contributing to the planning, designing, programming, and testing of the system.

Customer

The business skills of the customer complement the technical skills of the programmer. A customer on an XP project is a decision maker, and by writing user stories and ongoing involvement in the project, steers the direction of the development. An XP customer is also a tester and takes on the responsibility for writing the functional tests that ultimately become the acceptance tests for the finished system.

Tester

As both the programmer and customer roles take on the responsibility for writing tests in XP, the role of the tester switches to focusing on the customer. The tester takes charge of ensuring all tests are incorporated into an automated build process and communicates the results of test runs to the team.

Tracker

A key to successful planning is the ability to compare actual task completion times to estimates. Iterative development benefits from this ability, as the estimation process can be refined between iterations. The tracker role is responsible for collating the actual times and providing these figures as feedback to the developers. The tracker also gauges the progress of the team against the overall goals of the project and uses this information for planning purposes.

Coach

The coach is the XP process expert and advises the team on all matters relating to the implementation of an XP project. This role diminishes as the project progresses, as collectively, the whole team begins to pick up responsibility for the process.

Consultant

The role of the consultant is to inject technical knowledge into the team as and when it is required. Consultants tend to be transient members of the group who pass on their valuable technical skills by mentoring the team in a particular problem area.

Big Boss

The final role is for the individual who is ultimately responsible for the project. The role involves helping to guide and assist the team through problems, acquiring additional resources as required, and making some of the hard decisions around delivery in consultation with the team.

Now that we've covered the main points of an XP development, let's consider how well suited the process is for the development of a J2EE solution.

Adopting XP for Enterprise J2EE Projects

XP will be not be a perfect fit for all projects, since certain conditions must be present in order to get maximum benefit from the method. First, a business domain expert is required from the customer to work closely with the development team. This individual must be empowered to make key decisions about the direction and behavior of the system being developed.

The customer is not the only one who must commit to an XP development. Management must also back the approach and be prepared to embark on a project that may have uncertain requirements and no clear deliverables from the outset. This presents the manager with all manner of contractual challenges around price and delivery commitments.

For XP to work, the software engineers assigned to the project must be prepared to adopt its practices faithfully. XP is a disciplined process and requires teams to adhere to all of its practices in order for the process to operate effectively. Developers who don't want to work in pairs and resent other developers changing their code would be better off placed on other projectspreferably with another company.

Even if all of these conditions are in place, XP is still not a good match for all project types. To quote from Kent Beck's Extreme Programming Explained [Beck, 1999]:

There are times and places and people and customers that would explode an XP project like a cheap balloon.

So, how well does XP gel with a J2EE-based project? Well, XP is technology-neutral. The original C3 project was an object-oriented project developed in Smalltalk, and XP has been used effectively with other programming platforms since then, so the use of the J2EE platform should not be a barrier to adopting XP.

When J2EE projects do find themselves hitting the limitations of XP has more to do with the nature of enterprise development than with the J2EE platform itself. Enterprise developments tend toward large teams, with a current trend toward having split-site development using offshore resources.

XP works best with small teams averaging around 10 people, and with the team members in close proximity. Big team sizes are definitely an issue for XP, as the lightweight process lacks the necessary ceremony to coordinate large numbers of developers. Nevertheless, XP as a process is still evolving, and work is currently ongoing to determine how XP can scale for larger projects.

Another major barrier to the use of XP on enterprise projects is the contractual nature of these developments. A fixed-price quote with clearly defined scope is the norm for an enterprise system. Working to these contractual constraints requires a level of predictability that does not sit well with the low-ceremony approach of XP.

Instead, XP in its current form favors inhouse, collaborative projects. Projects of this type fit the profile for an XP project extremely well. Onsite domain experts are often easily arranged, and as the customer and development team all work for the same company, the contractual requirements are not so stringent. It is possible to operate an XP project with an external customer, but a good relationship must be in place for the process to prove workable.

To conclude, XP and J2EE can work well together, but pick your projects with care. Don't opt for an excessively lightweight process when the conditions call for something more substantial.

Key Points of XP

• Offers a deliberate and disciplined approach to software development

• Freely available and documented by numerous books and articles

• Lightweight and low ceremony

• Easy to learn and understand

• People-centric as opposed to document-centric

• Targets small- to medium-sized projects

• Less well suited to enterprise-sized projects