Home > Store

Extreme Programming Applied: Playing to Win

Register your product to gain access to bonus material or receive a coupon.

Extreme Programming Applied: Playing to Win


  • Sorry, this book is no longer in print.
Not for Sale


  • Copyright 2002
  • Dimensions: 7-1/4" x 9-1/4"
  • Pages: 376
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-61640-8
  • ISBN-13: 978-0-201-61640-8

Extreme Programming (XP) is a fundamentally different way to create software: simple, yet disciplined, lightweight yet powerful, flexible yet rigorous. It's catching on like wildfire, as developers who try it discover not only its effectiveness, but the pleasure it returns to their work. Extreme Programming Applied is the place to start for any developer or project manager preparing to use XP for the first time. In this book, two pioneers in XP practice offer a complete introduction to applying XP at all stages of the software development lifecycle -- design, testing, implementation, and deployment. They introduce XP's key principles in the context of actual development challenges, explaining why XP's "soft" approach is more appropriate to software development than the "civil engineering" paradigms that are so widespread nowadays. This book goes beyond explaining XP's elements: it shows how the pieces fit together, demonstrating exactly how to make XP work for real projects in real organizations. For all project managers, developers, software engineers, and others interested in more effective, flexible approaches to software development.


Related Article

Integrating XP into Your Existing Software Workshop

Web Resources

Click below for Web Resources related to this title:
Author Web Site

Sample Content

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:

Table of Contents

List of Pioneer Stories.




Introduction: Playing to Win!


0. XP Distilled.

The Planning Game.


Pair Programming.


Simple Design.

Collective Code Ownership.

Continuous Integration.

On-Site Customer.

Small Releases.

40-Hour Week.

Coding Standards.

System Metaphor.

The Practices Work Together.


1. The Courage to Begin.

The Organizational Imperative.

Your Role.

2. Introducing XP.

Bring a Friend.

Find a Target.

Assemble the Right Tools.

Driving Spikes.

The Lone Wolf.

A Single Pair.

A Small Team.

A Small Team with a Lead Developer.

It's All Right to Feel Awkward.

3. Taming the Resistance.

Where Resistance Comes From.

The Result That Matters.

What Not to Do.

4. Manager Resistance.

The Manager Perspective on Winning.

XP Is Too New to Trust.

XP Is Simplistic.

Pair Programming Is Too Expensive.

I Can't Afford a Full-Time, On-Site Customer.

XP Is Too Informal.

Be Wary of “XP-Lite”.

5. Developer Resistance.

Developers Are Different.

The Developer Perspective on Winning.

XP Is Too Simplistic.

I Won't Like Pair Programming.

XP Is Weird.

XP Doesn't Give Us Enough Information.

6. Having the Right Attitude.

Honesty and Trust.


Sweet Freedom.

II. First Things First.

7. The Bare Essentials.

The First Step.

The XP Essentials.

Remember the XP Values.

Think Simply.

Get Feedback Early and Often.


Be Courageous.

8. Exception Handling.

Handling XP Exceptions Like Code Exceptions.

An Odd Number of Developers.

The Customer Won't Write Stories.

The Customer Won't Write Acceptance Tests.

Management Sets Unrealistic Schedules.

Management Doesn't Like Your Estimates.

Management Won't Let You Pair.

The Cost of Tea in China Doubles.

9. Can We Talk?

Pair Programming.

Stand-Up Meetings.


Atmosphere and Environment.

It Doesn't Stop There.

10. Planning Roles and Reality.

How XP Planning Is Different.

How to Steer.

Out in the Open.

Requirements are a Dialogue—Not a Document.

Learning Roles.

The Customer.

The Developer.

A Tool to Introduce Reality.

How the Roles Work with Multiple Projects.

When Roles Are Clear.

The Xtreme Hour.

11. Project Planning.

Charting the Course.

The Planning Game.

The Customer Writes Stories.

The Developers Estimate.

Breaking Down Stories.

Back to Estimating.

Determining Iteration Size.

Sorting the Stories.

Exploration Phase.

12. Iteration Planning.

What Plans Are.

The Iteration Planning Game.

Task Exploration.

Iteration Plan Verification.

One at a Time.

Fill Your Bag.

How to Start Planning.

The Art of Estimation.


The Last Word on Iterations and Planning.

13. Write the Tests, Run the Tests.

Keeping Code Clean.


Tests as Documentation.

How to Write Tests First.

What to Test.

How to Start Writing Tests First.

Testing Challenges.

Testing User Interfaces.

Testing in Small Spaces.

Testing the Web.

Tests Have to Run Fast.

14. Stop the Maverick.

Code Quality.

The Need for Speed.

Reducing Risk.

How to Pair Program.

Pair-Friendly Space.

Don't Ignore Problem Children.

Taking It to the Next Level.

The Inevitable Objections.

When Not to Pair.

Unusual Pairs.

Personal Space.

How to Start Pair Programming.

15. Making It Right.

Being Ready for Change.

Making Change Possible.

Putting Learning into Your Code.

How to Refactor.

When to Refactor.

When Not to Refactor.

When to Stop Refactoring.

How to Start Refactoring.

Why People Don't Refactor.

16. Pulling It Together.

Maintaining Speed.

Reducing Risk.

How to Integrate Continuously.

How to Start Integrating Continuously.

Techniques to Make It Easier. Chapter 17 Staying on Process.

Why Teams Lose Their Way.

How to Get Back on Process.


18. Designing the Simple.

Defining Simplicity.

Why People Don't Keep It Simple.

Why Keep Things Simple?

How to Start Doing Simple Design.

Why Not Start with Simple Design?

The Essential Design Tool.

19. It's Everybody's Job.

What Collective Ownership Means.

Moving From “I” to “We”.

Why Have Collective Code Ownership?

How to Start Having Collective Code Ownership.

Why Not Start with Collective Code Ownership?

20. Where's the Customer?

Why Have an On-Site Customer?

On-Site Versus Available When Needed.

How to Get an On-Site Customer.

Why Not Start with an On-Site Customer?

21. Knowing When You're Done.

Customer Confidence.

Acceptance Tests as Documentation.

How to Write Acceptance Tests.

Automating Acceptance Tests.

What to Test.

How to Start Writing Acceptance Tests.

Why Not Start with Acceptance Testing?

22. Don't Get Distracted by the Code.

Why Have Coding Standards?

How to Start Having Coding Standards.

Why Not Start with a Coding Standard?

23. Overtime Is Not the Answer.

Why People Work Too Much.

What's Wrong with Burning the Midnight Oil?

How to Start Working Normal Hours.

Why Not Start with a 40-Hour Week?

24. Painting a Thousand Words.

Where the Concept of Metaphor Came From.

How to Start Creating Metaphors.

Why Not Start with a Metaphor?

25. Looking for Guidance.

Why You Do Need a Coach.

What If We Don't Have a Coach?

Rookie Coaches.

How to Coach.

Minimal Coaching.

How About a Player/Coach?

Why Start Without a Coach?

26. Keeping Score.

What to Track.

How to Track.

Why Not Start with a Tracker?


27. Selling XP.

Erasing Objections.

How to Sell XP.

The Results.

Proving It.

Developing a Track Record.

Relationships Sell.

28. XP and Startups.

The Target.

The Pitch.


Venture Capitalists.

Selling to Startups.

Strategic Initiatives: Startups in Disguise.

Joining Them.

29. Scaling XP.

Does Anything Really Scale?

Should You Need to Scale?

Why Can't XP Scale?

When to Scale.

How to Scale.

Reserving Judgment.

30. The Next Best Thing to Being There.

The Limits of Technology.

Can a Team Telecommute?

When to Try Distributed XP.

31. Measuring XP.

What to Measure.

The XP Challenge.

The Before-and-After Study.

What Having the Numbers Will Mean.

32. Where to Next?
Index. 0201616408T09252001


"You're a fool to think this will ever work."

People have said that to all of us about Extreme Programming (XP). We've said it to ourselves about XP.

People told Christopher Columbus he was nuts when he wanted to sail west. People told the Pilgrims this before they got on the Mayflower. People told many of the early settlers of the American frontier the same thing.

Yet they all headed west. Why? They believed there was something better out there, and somebody had to be the first one to find out if they were right. The journey itself was treacherous for each of them. Once they got to their destination, there were more dangers. Some they suspected ahead of time. Some were total surprises. Of course, they were scared. But, as pioneers, they had no choice but to face their fears head-on. Sometimes they died. Sometimes they lived to face the next life-threatening challenge.

Stories from these brave fools made it back to the people they left behind, and then to people they didn't even know. Those who may not have been brave enough to take the first journey, or who didn't have the opportunity, were encouraged. They became the next wave of pioneers. They were better prepared than the first wave. Bravery and success (mixed with the excitement of knowing the risk they were taking) encouraged another wave. It didn't come easily, but eventually the West was settled.

We are the early pioneers. We don't have all the answers. We have celebrated some victories. We've reflected on some failures. We certainly have learned a lot. These are our letters home. We hope they will encourage the next wave to head west.

Who Should Read This Book

We wrote this book for software developers and for technical managers who are interested in Extreme Programming (XP). Perhaps they don't know how to get started or don't know how to go further than they've already gone. Our goal was to create a practical volume that would provide advice based on real-world experience.

We assume that people reading this book have either read Kent Beck's Extreme Programming Explained or have otherwise gained a general understanding of what Extreme Programming is. Kent's book is a manifesto that makes the case for XP. We accept the case as made, and we move on to helping those who want to act on it.

If you are a developer or a technical manager even mildly interested in XP, we assume you have at least one of these five burning questions:

  1. Does XP work where it has been tried?
  2. How does it work?
  3. How can I make the case for it within my organization?
  4. What's the best way to get started, given the resistance I'm likely to face?
  5. Once I've made the case for it and gotten started, how do I make it work within my organization?

Although we may not be able to answer all of these questions definitively for you, we hope to give you enough guidance to act immediately.

How to Read This Book

You can read this book in three different ways:

  1. As a collection of stories about how various people (including us) have started using XP in their organizations
  2. As advice about how to start using XP in your organization
  3. As a virtual coach to use as you begin introducing XP into your organization in your own unique way

The list of pioneer stories provides a complete listing of all the stories in this book. Each story has a title that captures its primary thrust. You can read just these stories and get a feel for how to make the case for XP and how to start using it.

We embedded the stories within the chapters of the book, where we provide some context for them and some advice based on our own experiences. You can read the book from cover to cover, skipping the stories entirely (they are highlighted in the text) to get the advice in its nonillustrated form.

Perhaps the best way to read the book, though, is as a cohesive whole. The stories put the advice we're giving in the context of organizations and projects with human beings acted on by real forces. It is the next best thing to having tried XP yourself.

Ultimately, we hope you do try it yourself. Think of this book as an instruction manual for achieving the goal Kent outlined in Extreme Programming Explained.

XP on the Web

A good reference bookshelf is an invaluable tool. The Internet puts mounds of information at your fingertips, but it hides it under a lot of junk. Finding what you need can be a needle-in-a-haystack exercise.

If you want to find out more about XP and some of the things we've referred to in this book, check out our XP Portal at http://www.rolemodelsoft.com/xp. There you will find things like pointers to

  • Laurie Williams and Alistair Cockburn's research on pair programming
  • Integration procedures using VisualAge for Java Enterprise
  • A JAccept™ overview

We will update this portal over time.



A-B Acceptance testing, 6-7, 55
    as documentation, 235
    automating, 238-239
    customer confidence, 233-235
    reasons to test, 239-241
    refusals by management, 80-81
    selecting code to test, 239-241
    tracking, 270
    writing tests, 235-237, 240-243
Agile methodologies, future role, 311-312
Architecture (system metaphor)
    creating, 258-259
    origin, 257-258
    XP practice, 11
Attitudes toward XP approach
    freedom, 62-65
    honesty and trust, 59-61
    humility, 61-62
Automatic tracking, feedback, 271-278
Coach role, development teams
    basics of coaching, 265-266
    player/coach roles, 266-268
    reasons for needing coaches, 262-263
    repercussions of not having coaches, 263-264
    rookie coaches, 264-265
Code, programming standards, 10-11
    basics, 246-247
    reasons, 245-248
Code integration (continuous), 9, 71
    basics, 199-201
    risk reduction, 198-199
    speed, 197-198
Code ownership, collective, 9
    defined, 224
    initial steps, 224-226
    reasons for, 225
Code refactoring
    basics, 192-193, 195-196
    benefits, change, 190-191
    benefits, learning, 191-192
    resistance, 196
    timing, 193-195
    XP practices, 8, 71
Code, testing
    acceptance testing, 6-7, 55
    acceptance testing, as documentation, 235
    acceptance testing, automating, 238-239
    acceptance testing, customer confidence, 233-235
    acceptance testing, reasons to test, 239-241
    acceptance testing, refusals by management, 80-81
    acceptance testing, selecting code to test, 239-241
    acceptance testing, tracking, 270
    acceptance testing, writing tests, 235-237, 240-243
    unit testing, 6-7, 71
    writing tests, as documentation, 155
    writing tests, challenges, 162-165
    writing tests, clean code, 154-155
    writing tests, initial steps, 157-161
    writing tests, selecting code to test, 160
    writing tests, test/code cycles, 159
Coding standards, 10-11
    basics, 246-247
    reasons, 245-248
Collective code ownership, 9
    defined, 224
    initial steps, 224-226
    reasons, 225
Communication (XP core value), 4, 74, 76
    environment, 90-96
    pair programming, 84-86
    planning, 89-90
    role in planning, 99
    stand-up meetings, 87-89
Continuous integration of code, 9, 71
    basics, 199-201
    risk reduction, 198-199
    speed, 197-198
Core values (XP)
    communication, 4, 74, 76, 83-96
    communication, environment, 90-96
    communication, pair programming, 84-86
    communication, planning, 89-90, 99
    communication, stand-up meetings, 87-89
    communication, workplace environment, 90-96
    courage, 4, 74, 76, 82
    feedback, 4, 74-75
    feedback, activities to be tracked, 269-270
    feedback, automatic tracking, 271-278
    simplicity, 4, 8, 74
    simplicity, resistance to XP, developers, 46-48
    simplicity, resistance to XP, managers, 35-36
Costs, managers' reasons for resistance to XP, 36-39
Courage (XP core value), 4
    essentials, 74, 76
    realistic times for projects, 82
CppUnit (C++) testing, 161
CRC cards, design tools, 216, 220
Customer stories
    customers not providing, 80
    Initial Planning Game, breaking down stories, 129-132
    Initial Planning Game, sorting stories, 134-135
    Initial Planning Game, writing stories, 123-124
    iteration planning, breaking into tasks, 139-144
    role in planning, 104-107
    XP initial steps, 23 D
Debugging sessions, pair programming, 180-181
    distributed teams, 301-304
    estimations in Initial Planning Game, 125-129
    role in planning, 100-101, 103-104
    team's role in Planning Game, 5
    teams, coach role, 261-268
    teams, tracker role, 269-278
Developers, resistance to XP approach
    countering, with results, 30-31
    major sources, 30
    perspective of developers, 46
    reasons, dislike of pair programming, 48-50
    reasons, documentation weaknesses, 52-58
    reasons, simplistic, 46-48
    reasons, weirdness, 50-52
    tactics using XP, 31
Distributed teams
    reasons for trying, 303-304
    technology limitations, 301-302
    telecommuting, 302
    acceptance testing, 235
    lack of, resistance to XP approach, 52-58
    resistance of developers to XP, 52-58
    writing tests, 155
Driving spikes, 17
    XP initial steps, 23 E
Entrepreneurs, marketing targets, 291
Environment (workplace)
    aspect of communication, 90-96
    pair programming, 175-176, 185-186
    iteration planning, 144-147
    XP practice, 71
Exception handling. See also Resistance to XP approach, managers and developers
    management obstacles, estimates not accepted, 82
    management obstacles, no acceptance testing, 80-81
    management obstacles, no customer stories, 80
    management obstacles, unrealistic schedules, 81-82
    pair programming obstacles, 78-80, 82
Exploration phase, project planning, 135-136
Extreme Hour, role in planning, 114-117
Extreme Programming. See XP
Feedback (XP core value), 4, 74-75
    activities to be tracked, 269-270
    automatic tracking, 271-278
    basics, 270-271
Fill-your-bag approach, iteration planning, 145
Forty-hour week work schedules, 10
    initial steps, 254-255


We shouldn't ever have to survive another software project.

Survival is a good thing. But when it is your focus, it's not that fun or rewarding. In the end, you are not much better off than when you started. In some ways, you are worse off. That's not where you want to be. And once you've realized you survived, it certainly feels better, but you don't want to start the journey over again.

There are all sorts of books about surviving software projects. Some say that the best you can hope for is survival. Many experienced in the industry say the same thing. If you were counseling a young person about his future career options, you would not say, "Think about a career in software--with a lot of hard work, and by learning a few key techniques, you can survive."

If you are a professional reading this book, whether you just live in a world with room for improvement or dwell in the depths of despair, you are probably looking for something better than the status quo. You are hoping that Extreme Programming (XP) is something better, and you want to find out whether the promise that others have seen in XP has actually panned out. You see a lot of obstacles between you and that wonderful place you'd like to be. You wonder whether "The Promised Land" is even attainable, and whether the journey is worth taking.

Like many promising things that have come before it, XP is no silver bullet. It does not offer a formula for wild success on your next (or current) software project. On the other hand, XP, when executed well, allows you to shake off many of the problems of mainstream approaches that can keep you from succeeding.

To illustrate some of the problems with mainstream approaches, we offer the following composites of real people we have met in the software world.

The Pitiful Programmer

Many very intelligent programmers we know seem to go from one failed project to another. Often the next project seems full of promise. There's new technology to learn and you look forward to learning it. Often, you start with enthusiasm, but it goes south in a hurry.

It becomes clear that your leadership has made unreasonable promises and set the bar too high. The inevitable technical and organizational obstacles spring up, but the deadline does not change. Scope creeps. Maybe, after Herculean efforts (often at the expense of family, social life, and physical or mental health), the project actually produces something. Not something to be truly proud of, mind you, but something. Equally likely, the project gets cancelled, to no one's surprise. The warning signs of impending failure were all over the place and screaming for attention.

This is the norm. Being part of a project that provides an enriching learning environment, produces something good, and doesn't kill you along the way is a fantasy, an unattainable dream. The pitiful programmer comes to believe that success is just luck, and the chances of success are too slim to count on. The best you can hope for is to survive without being maimed.

The Die-Hard Developer

Many very intelligent and talented programmers we know seem to have overcome some great obstacles to produce software that actually ships. Life is not so bad, most of the time. You were given part of the software to develop, figured it out, used some of the best design practices in the industry, and worked hard to hit your deadlines. Then came integration.

On the project plan, there is this little block of time where everything comes together. You and everybody on the team cross your fingers. Soon, each of you finds out a few assumptions others made about your software. Of course, the process of getting there is not pretty. Things are going wrong and you have to spend just as much time defending your work as you do trying to get all of the software to come together as planned. You work late into the night to pull it out, but you are bruised and battered. The pristine software you submitted to be integrated has been patched and hacked in so many ways, it's barely recognizable. Management may appreciate these heroics or lay blame for the problems that required the heroics.

This is the norm. Being part of a project that provides a way to avoid these intense storms is a fantasy, an unattainable dream. The die-hard developer believes there has to be a way to avoid this, but hasn't yet seen it. The best you can hope for is to survive the storms to get to the next relative calm.

The Sad Sponsor

Many business people we know doubt that they'll ever get quality software delivered on time and within budget. Who can blame them? They ran the numbers before the project started. They vetted the numbers with all the right people and got a unanimous "go," after a painfully slow process in which the company spent a bunch of indirect money deciding whether to spend the direct money. Everyone was excited about the possibilities. Then reality set in.

Several months into the project, the software team started requesting additional resources in order to hit the target date. They blame you for changing the requirements or for providing vague requirements in the first place. After reluctantly cutting into the hoped-for profit, you learn that the software team doubts it will ship anywhere close to the planned release date. And the "minor" functionality changes that some stakeholders requested produce a groundswell of resistance from the developers, who get the shakes when asked to deliver. They seem to have forgotten that the stakeholders are the ones paying their salaries.

The software must ship or the budget will have been blown with nothing to show for it. Even if it does ship, there's still a good chance you will get fired for incompetence because the incremental profit promised won't materialize. The next release doesn't look any better. Is there any chance you can survive in this organization with this reputation?

This is the norm. The best you can hope for is to survive without looking like an idiot.

The Smelly Software

Both the developer and the sponsor are battered and bloody at the end of the typical project. The project delivered either subpar software or decent software over budget. The end user identifies a handful of significant problems in the software. There are some nice features, but not the ones that really give the users the desired bang for the bucks they spent. Everyone is at least a little bit ashamed of what they shipped . . . in private.

This shouldn't be surprising. Scope got out of hand fast and changing requirements invalidated the original design. Pretty soon, nobody even remembered the original design anymore. Under the intense time pressure, developers took all sorts of shortcuts and did all sorts of dumb things. The sponsor spent a lot of time dealing with the concerns coming out of development and missed some significant needs of the end users. Remember, sponsors, developers, and programmers are all just trying to survive. Communication broke down, too. Who had time for meetings or coordination? Alternatively, who had time for anything but meetings and rationalization?

In the end, the software they created is not in the best shape. It's full of bugs, or is a patchwork of fixes commented with "Not sure why this works-- DON'T TOUCH!" It's brittle. Changing it is so risky that developers perform unnatural acts to squeeze new features into spots not made to accept anything new, because that's the only way to avoid new bugs. Management and customers don't understand why it seems to be so hard to get the new features in for the next release. Now the pressure is on again.

Developers don't want to produce software like this. Customers don't want to buy and use it either.

How Things Got So Bad


Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020