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
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:
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 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.
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.
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.
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.
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:
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.