RUP and XP, Part I: Finding Common Ground

by Gary Pollice
Evangelist, The Rational Unified Process
Rational Software

eXtreme Programming (XP) is hot! Attend any software development conference today and XP presentations are standing room only. Why? I have observed that XP speaks to the programmer in almost every technical manager and practicing software developer. We all remember simpler times when we sat at the keyboard and coded. Some of us were even happy testing and fixing the code because we wanted it to be perfect. Our code was our legacy to future generations of programmers. And we all had heroes, legends who cranked out more code with fewer errors than we thought humanly possible.

XP hints that we may yet return to the "good old days."

Why don't tears of nostalgia well up in our eyes when we think of the Rational Unified Process (RUP)? Because RUP^® contains the dreaded "process" word, and most of us have had bad experiences with process. We recall that it was too heavy and too restrictive. Something that wasted our valuable time; something that kept us from coding. But the process itself was not the real culprit: our bad experiences stemmed from the way the process was implemented and used.

In this two-part series, we will look at how to make the implementation and use of RUP a good experience. We will see how it can be used effectively for a small project, and specifically how to incorporate XP practices into the broader scope of a RUP-based project. This month's installment will examine the areas where the two come together. Next month we will look at how RUP differs from XP, when and why you need to consider the differences, and what benefits accrue with the added strengths of RUP.

If you're not familiar with the two processes, then start with my overviews of XP and RUP.

How do you decide on the right process for a software development project? If you are considering using XP as your process, the first question you need to ask and answer is: Can I actually use XP for this project? This may not be as easy as it sounds. There are lively debates on what makes a project an eXtreme project (see http://c2.com/cgi/wiki?AreYouDoingXp for one view). If you don't refactor your code continuously and write tests before you code, for example, then are you doing XP? In truth, many, if not most, so-called XP projects do not follow XP in an orthodox way. Most use some XP techniques; few use them all.

If you're thinking of using XP straight up, here are some more specific questions you should ask yourself:

• Is the project team small (ten people or less)?
• Is the team co-located, and willing and able to do pair programming?
• Do we have a commitment for an on-site customer?

If you answered "no" to any of these questions, then you may not be a candidate for a full-fledged XP project. You may, however, be able to use the RUP and incorporate selected XP techniques into it.

Unlike XP, which focuses narrowly on small, co-located teams with on-site customers, RUP is broader and more flexible. It addresses many styles of software development projects and urges users to adapt its elements to suit their specific projects. It is not hard to imagine an adaptation of RUP that matches XP very closely. In fact, this is exactly the claim that Robert Martin makes for his dX Process.¹

XP Practices and the RUP

The focus of XP is code: writing the code, keeping it simple, and getting it correct. This is a good thing, as far as it goes. If you build software, ultimately it comes down to delivering executable software to your customers.

Let's look at nine specific XP practices to see how they complement or overlap with the RUP. For each practice, we will briefly discuss benefits as well as limitations and hidden assumptions. See the XP overview for a brief description of each specific practice.

Everything Starts with Planning

When it comes to planning, RUP and XP agree: plans change, and you cannot, practically speaking, plan a complete project in detail. The best approach is to anticipate changes and ensure that you control the associated risks. According to XP, you should prioritize the "stories" you want your system to fulfill, and get technical estimates for the effort required to implement them. Is prioritizing stories any different from prioritizing use cases? Not really, if you equate stories with use cases. Some of the example stories from XP literature are not really use cases, so it may not make sense to equate the two. A story describes a unit of work, and XP assumes that the story's context is obvious. A use case provides a complete set of operations that provide value to a system user. I believe stories and use cases complement each other, and that a use case can be realized through multiple stories. A use case speaks to all stakeholders, whereas stories speak in more detail to developers. You can produce use-case realizations (according to the RUP) by filling in a complete, more detailed context for the stories.

Alistair Cockburn says that stories are promises for conversations between the on-site customer and the programmer. These conversations are of great value, and the RUP specifically asks you to consider capturing their results in use cases and other requirements artifacts. XP implies that you should capture the results but provides little guidance on how to do it. In XP, the final resting place for requirements or design decisions is the code. Unfortunately, code is not an effective communication medium for all stakeholders.

Getting technical estimates from the developer who will implement a feature is good practice. RUP does not go into detail about how to obtain these estimates, but if you have confidence in the developer, then adopt the practice as part of your planning process. In fact, go beyond this practice: When you get into the details of project deliverables, do estimates for documentation, training, support, and manufacturing.

Simple Design: No Arguments

Every technical discipline preaches simplicity. XP tells us to build the simplest system that meets current requirements, recasting this principle as You Aren't Going to Need It. What this means is that you should implement things when you actually need them, not when you realize that you might need them in the future. The RUP says almost the same thing using different words and at different levels: Manage your requirements, continually prioritize, and assess progress. Well-defined, prioritized requirements simplify the developer's decision making about what to do. The RUP also encourages the use of components and the Unified Modeling Language to help manage design complexity.

It is easy to misinterpret the XP advice and mistakenly assume that you do not have to pay attention to infrastructure and architecture. But simple design does not mean that you can ignore required infrastructure or architecture. There is a sharp difference between RUP and XP in this area, which we will discuss next month under the XP practice of "metaphor."

Testing: The Last Word?

Test first, then code! This is wisdom from XP, and it is good. The other testing pearl from XP is that the customer provides the acceptance test. Programmers write unit tests to ensure that the code does what they think it does. Customers write acceptance tests to ensure that the system does what it is supposed to do. RUP has a general framework for testing and provides guidance on how to write effective tests. In addition to unit and customer written tests, others may be required: for example, load tests for Web sites. Combine RUP and XP, and you get an excellent quality focus for your team.

In XP, the development team uses the test results to decide whether the system is ready for the customer. If the system passes all acceptance tests, then the software is ready. RUP suggests other acceptance criteria in addition to testing. Depending upon the project, you might consider including customer training, on-site installation, documentation, and several other items in your product acceptance criteria. Simply because a system passes the tests does not ensure that a programmer (or programming pair) has not inserted a trap door or some other time bomb in your software. Sometimes, depending upon the type of system, you need more rigorous code inspections by independent auditors.

Refactoring: A Little Goes a Long Way

Refactoring is the act of rewriting code to improve it. It is also a technique for keeping the design simple. RUP does not address code refactoring, but that does not mean you should not consider it. Be aware, however, that refactoring may create a risk for your team. What's simple to one programmer may be complex to another. If you do too much refactoring, then the team may thrash around and lose valuable time developing the code.

Pair Programming: Are Two Heads Better Than One?

There is evidence that pair programming is an effective way to improve programmer productivity. Programmers remain focused, and because they get immediate feedback, quality improves. Pair programming is one way to avoid code reviews, but it places some constraints on a project team:

• The team must be in one location.
• Paired team members must have compatible personalities plus well-matched programming skills.

Continuous Integration: Do One Build or More Per Day

Every programmer on an XP project must be able to change code and ensure that it works, not just for unit tests but also for acceptance tests. This requires frequent builds: one or more a day. This practice is an excellent one. In order for it to really work, however, you need powerful configuration management tools and an effective process for using them. The RUP provides general guidelines for continuous integration as well as specific information on using Rational ClearCase. In fact, at Rational, we perform daily integrations on the complete Rational Suite product family.

Forty Hour Work Week: No Sleeping Under the Desk

What a great idea! Is it practical for your organization? Studies indicate that most people experience rapidly diminishing returns when they invest more than forty hours in their work -- especially when it is habitual. An XP project forbids two consecutive weeks of overtime.

On-site Customer: A Must-Have?

Originally, XP said, "A real customer must sit with the team, available to answer questions, resolve disputes, and set small-scale priorities." This has been further refined to, "An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them."

The RUP is more flexible. Although it has always maintained that the customer, in fact all stakeholders, must be adequately represented in steering a project, the RUP also acknowledges that it is not always possible or desirable to have a real customer co-located with the development team. Instead, RUP defines several roles that are responsible for determining the project goals, scope, and so on, and says that a customer (on-site or not) or some other appropriate person in the organization can perform the activities mapped to these roles. It's not important whether the person is an actual customer, or whether he or she is actually on site. What is important is that the person be available to clarify issues, and capable and responsible enough to produce the information necessary for the team to progress as quickly as possible -- including feedback in a form the team can understand.

Coding Standards: Have Them and Use Them

No one is going to argue against having coding standards. But what is really important? To use them! It doesn't matter what the standards are as long as everyone uses them. The RUP provides three coding standard examples to get you started: Ada, C++, and Java. As a complement to these coding standards, the RUP also encourages that you define architectural mechanisms, which standardize not only the language of the code, but also its structure and usage (error handling and transaction locking are examples of common mechanisms).

Summary

As you can see, there is significant agreement between RUP and XP on nine of the twelve XP practices. Typically, RUP provides complementary guidance for doing more to address specific risks.

As you evaluate both processes vis à vis your next project, it's important to keep in mind this primary rule:

Ask yourself, "If we don't perform a specific activity, produce an artifact, or adopt a practice, will anything bad happen?"
If the answer is "no," then don't do it!

Next month we will look at the three remaining XP practices and discuss additional pitfalls associated with XP practices. And finally, we'll examine what important areas XP does not address.

¹ See http://www.objectmentor.com/publications/RUPvsXP.pdf, a chapter from Martin's forthcoming Object Oriented Analysis and Design with Applications, Third Edition, from Addison Wesley.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

RUP and XP
Part II: Valuing Differences

by Gary Pollice
Evangelist, The Rational Unified Process
Rational Software

In the last issue of The Rational Edge, we looked at the common ground between the Rational Unified Process (RUP^®) and eXtreme Programming (XP). They certainly have a lot in common. This month, in Part Two of our comparison, we look at the last three XP practices and at some areas of RUP not covered by XP.

There are three XP practices we deferred discussing until this issue. They are:

We will discuss each of these. But first, I'd like to point out that the set of XP practices we are talking about is the original twelve practices set forth by Kent Beck in his book Extreme Programming Explained: Embrace Change, published by Addison-Wesley in 1999. As of March 15, 2001, there were several additional supporting practices listed on the Extreme Programming Roadmap page: http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap. This indicates the dynamic and somewhat experimental nature of XP, which is not necessarily a bad thing. Any process needs to be dynamic and keep up-to-date with proven best practices. At the end of this article we will also look at some ways RUP and XP can work together to provide a good experience for software development project members.

Small Releases: How Small and Released to Whom?

What is a release? Depending upon how you answer this question, RUP and XP can seem quite similar in their concepts of a release. RUP defines a release as: "...a stable, executable version of product, together with any artifacts necessary to use this release, such as release notes or installation instructions."¹ Furthermore, according to RUP, releases are either internal or external. By this definition, a "release" creates a forcing function that ensures a shippable product, rather than a system that is only 80 percent complete. XP defines a release as "...a pile of stories that together make business sense."² In much of the discussion about small releases on some XP Web pages, the practice of small releases seems to coincide with the practice of continuous integration.³ If you interpret the stories to mean the code as well as any artifacts necessary to use the release, and you accept the release as either internal or external, then the RUP and the XP concepts of a release are almost identical.

RUP invites you to consider more than just code. A release, especially an external one to the customer, may prove useless unless accompanied by release notes, documentation, and training. XP addresses code and assumes the rest will appear. Since code is the primary artifact of XP, the others need to be derived from it. This implies certain skills that may not be obvious. For example, technical writers might need to be able to read the code to understand how the system works in order to produce the documentation.

I have talked with several people who assume the frequent releases in XP are all to be delivered to an external customer. In fact, XP is not clear about this. In Extreme Programming Installed, the authors urge you to get the code into the customer's hands as frequently as possible.⁴ The fact is, in many organizations customers cannot accept frequent software updates. You need to weigh the benefits of frequent delivery against the impact on the customer's ability to be productive. When you are unable to deliver a system to the customer, you should consider other ways of getting feedback, such as usability testing. On a RUP-based project, you typically deliver to the customer in the last construction iteration as well as in the transition phase iterations.

Collective Code Ownership: Yours, Mine, and Ours

XP promotes "collective code ownership," which means that when you encounter code that needs to be changed, you change it. Everyone has permission to make changes to any part of the code. Not only do you have permission to make the changes -- you have the responsibility to make them.

There is an obvious benefit with this practice. When you find code that needs to be changed, you can change it and get on with your work without having to wait for someone else to change it. In order for this practice to work, however, you need to also practice "continuous integration" and maintain an extensive set of tests. If you change any code, then you need to run the tests and not check in your code changes until all tests pass.

But will collective ownership work everywhere? Probably not. Large systems contain too much content for a single person to understand it all at a detailed level. Some small systems often include code that is complex due to its domain or the function it performs. If a specialist is required, then collective ownership may not be appropriate. When a system is developed in a distributed environment, it is not possible for everyone to modify the code. In these cases, XP offers a supporting practice called "code stewardship."⁵ With code stewardship, one person, the steward, has responsibility for the code, with input from other team members. There are no guidelines when to apply code stewardship instead of collective code ownership.

Collective code ownership provides a way for a team to change code rapidly when it needs changing. Are there any potential drawbacks to this? If you consider all the ways code is changed, then there are some things you may want to control less democratically, in a centralized way -- for example, when code is modified because it lacks some functionality. If a programmer is implementing a story (or a use case, or a scenario), and requires behavior from a class, collective code ownership allows the class to be modified on the spot. As long as the system is small enough for a programmer to understand all of the code, this should work fine. But as the system gets larger, it is possible that the same functionality might be added to code that exists somewhere else. This redundancy might be caught at some point and the code refactored, but it is certainly possible for it to go unnoticed and for the functionality to begin diverging.

You may want to start a project using collective code ownership to allow your team to move quickly. As long as you have good code management tools and effective testing, then it will work for you -- up to a point. As a project leader or manager, however, you need to be on the lookout for the point when the code base becomes too large or too specialized in places. When this happens, you may want to structure your system into an appropriate set of components and subsystems and ensure that specific team members are responsible for them. RUP provides guidance and other help on how to structure your system.

System Metaphor: It's Like Architecture

A metaphor is a figure of speech that allows us to make comparisons. It is one way that we learn: "A motorcycle is like a bicycle, but it has a motor attached." XP uses a system metaphor instead of RUP's formal architecture. This system metaphor is "...a simple shared story of how the system works. This story typically involves a handful of classes and patterns that shape the core flow of the system being built."⁶> Based on comparisons with familiar things, patterns help us understand new and unfamiliar things.

And indeed, the XP system metaphor may be a suitable replacement for architecture in some cases, but usually only in small systems. For many, if not most, software systems, you need more than a simple shared story. How much more you need depends upon many factors.

By contrast, RUP is an architecture-centric process.⁷ Architecture is more than a metaphor, although it may include several metaphors. Architecture is concerned with structure, behavior, context, usage, functionality, performance, resilience, reuse, comprehensibility, constraints, trade-offs, and aesthetics. It is usually not possible to capture all of this in a simple shared story. Architecture does not provide a complete representation of the whole system. It concentrates on what is architecturally significant and important in reducing risks.

RUP provides a wealth of guidance on constructing and managing architecture. It helps the practitioner construct different views of the architecture for different purposes. ⁸ The different views are needed because there are different aspects that need to be highlighted and different people who need to view the architecture.

A RUP-based project will address architecture early. Often an executable architecture is produced during the Elaboration Phase. This provides an opportunity to evaluate solutions to critical technical risks, and the architecture is built upon during subsequent construction iterations.

An executable architecture is a partial implementation of the system, built to demonstrate selected system functions and properties, in particular those satisfying non-functional requirements. It is built during the elaboration phase to mitigate risks related to performance, throughput, capacity, reliability and other "ilities", so that the complete functional capability of the system may be added in the construction phase on a solid foundation, without fear of breakage. It is the intention of the Rational Unified Process that the executable architecture be built as an evolutionary prototype, with the intention of retaining what is found to work (and satisfies requirements), and making it part of the deliverable system.⁷

What's Not Covered by XP That Is in RUP?

Your project may be able to use XP for developing the code. If not, then you may need to add some additional process, but just enough to reduce your risks and ensure that you are able to deliver the right product to your customers on time.

However, when you look at a development project as a complete set of deliverables, code, documentation, training, and support, there are many things RUP addresses that are not considered in XP. Again, you need to determine whether they are needed for your specific project. The following list provides things you may need to consider. The list is not exhaustive. You can find additional information about these items in the Rational Unified Process.

Mix and Match for Best Results

Process diversity is important.⁹ One size does not fit all projects. The process you use for your project should be appropriate for it. Consider what your project needs and adopt the right approach. Consider all aspects and risks. Use as much as you need, but neither too little nor too much.

RUP and XP provide two different approaches to software development projects. They complement each other in several ways. XP concentrates on code and techniques for a small team to create that code. It stresses face-to-face communication and places minimal effort on non-code artifacts. RUP is a process framework that you configure for different types of projects. It invites you to consider risks and risk mitigation techniques. RUP is often misinterpreted as being heavy because, as a framework, it provides process information for many types of projects. In fact, a configured instance of RUP may be very light, depending upon the risks that need to be addressed. It may incorporate some of the excellent techniques of XP and other processes if they are appropriate for the project at hand.

If my project is only about creating code, I may use just XP. However, almost all of the projects I work on require initial business decisions and planning, complete documentation, support, and deployment to customers. For this reason, I would more likely start with RUP and use the appropriate XP practices that will help my team move ahead quickly and mitigate real risks the project faces.

As a software engineer, I try to have a well-stocked toolbox of techniques, processes, and tools that help me succeed. I'm glad to have both RUP and XP as part of my collection. More techniques in my toolbox means that I can provide better value to my project and my organization. In addition, as a project manager or process engineer, I can create an instance of a process for a project that addresses the organization's need for controls while providing individual project members with an environment that can be fun and satisfying.

¹ Rational Unified Process Glossary.

² Kent Beck, Extreme Programming Explained: Embrace Change. Reading, MA: Addison-Wesley 1999, p.178.

³ http://c2.com/cgi/wiki?FrequentReleases.

⁴ Ron Jeffries et al, Extreme Programming Installed. Reading, MA: Addison-Wesley, 2000, p.50.

⁵ http://c2.com/cgi/wiki?CodeStewardship.

⁶ http://c2.com/cgi/wiki?SystemMetaphor.

⁷ This is described in Philippe Kruchten, "The 4+1 View of Architecture." IEEE Software, November, 1995.

⁸ This definition is taken from the Rational Unified Process glossary.

⁹ For more information on process diversity, see Mikael Lindvall and Iona Rus, "Process Diversity in Software Development." IEEE Software, July/August 2000.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!