Home > Store

Manager Pool, The: Patterns for Radical Leadership

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

Manager Pool, The: Patterns for Radical Leadership

Premium Website

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


  • Copyright 2002
  • Edition: 1st
  • Premium Website
  • ISBN-10: 0-201-72583-5
  • ISBN-13: 978-0-201-72583-4

What if--instead of a programmer pool--there were a manager pool, from which self-selected software developers chose the leader of their project? Would you be chosen? Can you lead developers to produce more creatively and proficiently?

As savvy high-tech managers know, the traditional, industrial models of management do not apply to the fluid and dynamic software development environment. Instead, technical management must formulate a more flexible model of management that can grow and change with the technology. The patterns paradigm that has transformed much of object-oriented software development can be applied to the management side of development. The patterns approach enables managers to identify, understand, and handle recurring management challenges that are common to many software development projects.

The sixty-one management patterns featured in The Manager Pool offer insight into the relationships between developers and their leaders, showing how teams can better work together to develop software. Based on years of experience in the software development trenches, these patterns address many different aspects of technical management, from the dynamic nature of software development, to communicating with the unique programmer personality, to organizing the workspace.

The patterns are organized into several overarching themes: psychological and retentive patterns, behavioral and expulsive patterns, strategic patterns, tactical patterns, and environmental patterns. Each pattern lays out the problem; discusses the context, related issues, and examples from industry; and finally offers a solution. You will read about such patterns as:

  • Leviathan--Software development projects are mysterious beasts, too deep and swift for a manager to fully understand or document. How do you know what to control directly, and what to leave to your developers?
  • Geek Channeling--You are responsible for keeping your team in the corporate loop and from spinning in random directions.
  • Tribal Language--Understand the cryptic and sometimes evasive language of developers so that you can have some insight into the substance of what is being said.
  • Overtime Detox--Oppose the temptation of overtime. Resist pressure to compress schedules without corresponding feature reduction, staff increase, or both.
  • The Gauntlet--Apply a legal-like standard of probable cause to investigate slackers and other problematic team members.
  • Train Hard Fight Easy--Despite the expense and time, train the team as a unit in relevant technologies to give everyone the same tools and language and so that the team is not using the project itself as the primary learning experience.
  • Fall on the Grenade--No matter who is at fault, take the responsibility for solving a serious problem in the project. Stand up and take the heat when the problem is unrecoverable. Then, move on.
  • Unique Place--Make your work environment unique, inspirational, and fun, so that you can retain your most talented employees. Think about perks, physical space, and entertainment.

Entertaining to read, insightful, and practical, The Manager Pool will provide you with the understanding and knowledge to communicate more effectively with your development team, lead them through to a successful project, and hence propel your own career.


Sample Content

Online Sample Chapter

How to Be a Better Manager — the Light Touch

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:

Table of Contents


Introduction: The Manager Pool.

Patterns for Radical Leadership.

The Patterns Form.

The Vision.


 1. Guiding Hand.
 2. Total Commitment.
 3. Leviathan.
 4. Drama.
 5. Metaphor.
 6. Switzerland.
 7. Good Service.
 8. Whole People.
 9. Cultural Competence.
10. Hover Shoes.
11. Blowhole.
12. Geek Channeling.


13. Exhibitionism.
14. Shameless Ignoramus.
15. Too Clever by Half.
16. Forty Whacks.
17. Tribal Language.
18. Social Jester.


19. Direct Action.
20. Outcome Based.
21. Get a Guru.
22. Home Field Advantage.
23. Overtime Detox.
24. Defense de Pisser.
25. The Gauntlet.
26. Push the Customer.
27. Finish Line.
28. Inoculation.
29. Just Say No.
30. Grease the Wheel.
31. One by One
32. Train Hard, Fight Easy.
33. Trial Project.
34. Secret Stash.
35. Defeat.
36. Casual Duty.


37. Spanish Ounce of Gold.
38. Significant Events.
39. Herding Cats.
40. Divide and Conquer.
41. Peer Pressure.
42. Passengers Push.
43. Decipher Discontent.
44. Backfires.
45. Enough Rope.
46. Rotten Fruit.
47. Featurectomy.
48. Containment Building.
49. Cargo Cult.
50. Cop a Plea.
51. Fall on the Grenade.
52. Abandon Ship


53. Living Space.
54. Unique Place.
55. Ball Court.
56. Private Space.
57. Public Space.
58. Geek Space.
59. Formal Space.
60. Fuel.
61. Vacation.
Don and Carol's List of Culturally Relevant or Iconic Artifacts.
Index. 0201725835T10052001


Introduction: The Manager Pool


The Manager Pool is a collection of patterns aimed at understanding and fulfilling a new vision regarding the relationship between software developers and those that lead them. This vision contains two basic elements. The first is that the effective organization radiates from a fundamental respect for individual uniqueness. The second holds that successful software development is a generative result of enlightened management, rather than a direct result of intrusive and controlling management.

The literary form known as patterns is used to express our observations and proves ideal for this effort, because a pattern expression implies that there are as many ways to fulfill the ideas presented within a pattern as there are readers. The use of the pattern form demands rigor in creation, yet in use it provides an inherent flexibility. Like a fluidly adaptable blueprint, its application permits software managers and developers alike to negotiate the particular reticulations of their daily work lives.

Drawn from collective experiences in the actual milieu of software development in companies both large and small, the sixty-one patterns contained in this book seek to illuminate how people--staff and management--can successfully work together to create great software products. Independent of technologies, processes, tools, or methodologies that are too often mistaken as the means of production, the fundamental conviction underlying this book is that it is always the people that matter most. As such, we hope that the patterns in the Manager Pool put to rest the notion that management is merely charts and graphs, technology and methodology, and instead demonstrate that to truly lead a team of talented software developers is to trust in their creative abilities and believe in their good intentions.

Have you ever noticed that software geeks love new stuff--new hardware, new operating systems, new languages, and new techniques? Mostly, though, geeks thrive on innovation--big ideas! Many not only embrace new ways of thinking, but also they often become true believers, exhibiting a fervor that is not so distinguishable from rabid evangelism. Although this may say nothing about the ultimate truthfulness or usefulness of a particular notion, some of these ideas do result in phenomenal breakthroughs of thought, whereas others are pathetic failures. Patterns is one of these potential "eurekas!" However, it remains to be seen whether this is really transcendent thinking or just another silly distraction.

With the widespread use of object-oriented technologies, the discovery and use of patternsto help build reusable software is one of the trendiest and most promising movements in software design and development. In fact, if you’re reading this book, chances are you already have, or will, sign an expense voucher for Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson, and Vlissides, Reading, MA, Addison-Wesley, 1995). Although concerned primarily with software design, in the wake of this popular book an entire patterns culture has evolved that seeks to redefine the relationships between software development, software developers, and the broader society to whom we are all ultimately obliged.

Historically, this particular concept of patterns goes back quite a bit further than 1995 and the publication of Design Patterns, to the effusive efforts of architect Christopher Alexander to discover and capture the qualities of those places that make people feel most alive. Although his legacy inspires from mild interest to fanaticism, his contributions are accepted universally by architects and software engineers alike for providing a common vocabulary that can be used in defining patterns.

Christopher Alexander believed that he could help people to build homes and communities that would reflect and support their lives to the utmost degree. By extracting patterns he observed in the buildings and towns of many cultures, he hoped to document those structures that ministered to our basic human and social needs and that made people feel alive. He believed that those things that fulfilled these needs were motivated by principles that could lead to tangible, objective, actionable strategies. It was his form of documenting these observations that have come to be called patterns.1

Alexander described patterns in The Timeless Way of Building:

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. . . . It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing.2

And from patterns, we build pattern languages:

The structure of a pattern language is created by the fact that individual patterns are not isolated.3

In time such languages become alive themselves:

Yet, changing as it is, each language is a living picture of a culture, and a way of life.4

In this work, the authors are concerned with improving the human facets of the computing experience. We believe that the use of patterns is about going beyond technique in a movement toward the essential core of successful software development--toward us, your developers. Tools don’t develop software. Methodologies don’t develop software. People develop software. And the people that develop software are not motivated in the same way as those in other aspects of the development process. The whole notion of career for many software developers is something completely different from what one would find among executives, marketing specialists, salespeople, or mid-level managers. A satisfied engineer may spend his or her entire career in the same nominal position, learning and creating new "stuff" for more than 25 years without a feeling of failure or regret when retirement finally comes. Would an entry-level marketing hotshot or a finance wizard with a freshly minted MBA be satisfied with a similar career trajectory? Probably not. Despite the many management gurus who believe that motivation is motivation is motivation, regardless, we know that things are different down on the cube farm. We’ve lived there for a long, long time.

The authors have many years of experience in the trenches of software development and have seen a lot of trends and techniques come and go, mostly with little cumulative impact with how we ultimately do our jobs. Despite the dearth of actual improvements in how we produce software, software developers continue to see development cycles become shorter while the days get longer. The time has come to retire the old industrial models of management. The environment has become too fluid, the forms too dynamic, for us to cling tightly to old concepts, or to any concepts for that matter, that cannot flex to accommodate all the changes yet to come. These patterns are about people working together to develop software. This book is about the relationships among these people, and, more specifically, their relationships with their leaders.

It is in the spirit of Christopher Alexander that the authors of this book use this literary form to help technical staff and leadership better communicate within their ranks. More important, however, we hope this book will provide managers with insight into the tribe that is the development community, offering the tools they need to communicate more effectively with their development staffs.


To assist your understanding of the material, it helps to understand the form itself. With each pattern described in this book, you will often find a picture that helps set the tone or that serves as an example of what we are relating. You will find an assertion of the problem in bold type, followed by a discussion of the forces, context, and related issues. This is followed by a solution in bold type, and sometimes by our basis for making such statements. Each pattern has a name that we have carefully chosen so that it may become a handle for the pattern. You will discover that these handles are referenced throughout the book, creating a web by which the patterns are interrelated and rely upon each other to be perfectly fulfilled. Any time a pattern is referenced, it is referenced in capital letters in special typeface, as in FALL ON THE GRENADE, or DECIPHER DISCONTENT. Flip through the book, as necessary, to fully enjoy the patterns form. In fact, it is possible to experience the book by only reading the bolded section of the patterns as they create problem-solution pairs. When you find something particularly interesting, go back and read the entire pattern. We hope that in time you will find yourself using a kind of shorthand in your daily adventures: "He didn’t survive the GAUNTLET. We might have to drop the ROTTEN FRUIT and surround the project with a CONTAINMENT BUILDING."

Our hope is that by using this form, you will be able to grasp the entire collection of these patterns as a whole, within which there are a variety of combinations in which they can be applied. Our further hope is that you will come to understand a bit more about the special nature of your software developers. Christopher Alexander wrote:

Its result is to allow things to be alive--and this is a higher good than the victory of any one artificial system of values. The attempt to have a victory for a one-sided view of the world cannot work anyway, even for people who seem to win their point of view. The forces which are ignored do not go away just because they are ignored. They lurk, frustrated, underground. Sooner or later they erupt in violence: and the system which seems to win is then exposed to far more catastrophic dangers.5

As ubiquitous as software has become in our lives, while at the same time becoming increasingly invisible, the software development community has a lot to answer for and a lot to be proud of as well. It is early in our history, but that history is an accelerated one, one that will propel us beyond our ability to shape it if we do not become conscious of what we do and, more important, why we do what we do.

We are entering a new era, one in which work-life balance is replacing pure ambition and where the measure of personal success is not in power or money but rather in the way in which one’s work supports a life. We think that this is a good thing, and we cast this modest tome into the sea in hopes that it will inspire those unknown to us to further humanize the workplace and help others to feel more alive. The generative, though perhaps seemingly indirect, effect of feeling more alive will be to produce more creatively and proficiently.

A Note on Our Particular Use of the Form

We primarily use the form as a literary device. Although it is fundamental that patterns be observed, we have taken the modest liberty here and there to document our collective dreams or ideas rather than hard examples in the real world. This may violate some notions in the patterns community that something should be observed in three separate instances, but we have not been so rigorous in all instances. If the reader prefers such rigor, then those patterns not meeting this criterion should be ignored (but read them anyway). Perhaps the dreams will be infectious.


Think of the traditional rural county fair, where one can watch the farm kids display the animals they have raised to be viewed; judged for excellence based on a variety of elements, such as weight, luster of coat, and overall health; and ultimately to be bought at auction. Of course, ultimately they are all sliced into steaks or ground into hamburger.

The Manager Pool is our hoped-for paradigm for high-tech management of the future. Today, teams do not select their managers. Projects are started under a particular manager’s aegis, and then either team members are assigned to the task or the manager is granted members from the organizational pool. In some critical instances where the project is high profile or strategic, teams even may self-select the most fit members for the task. But teams never select their managers.

Which begs an interesting question: In a world in which teams select their managers from a pool, would you be selected? Just how secure are you in your ability to lead your team into a bold new age where information technology touches all? How do the people you lead really feel about you? Do you even care? What if you stood among your peers while self-selected teams shopped for a manager? Would you be a prime pick? Or as Christopher Alexander predicts, is your system of management selection leading to catastrophic failure?

I know software developers, you may be thinking. A bunch of whiny geeks with fat 401K plans, now dishing out advice and implying that I’m as useful as a cow. Besides, left to their own devices, the nerds you know would choose only people who are weak or easy to manipulate to manage their teams, or who are just good-natured saps that they can push around and leave all the superfluous work to.

We admit it, this sounds amusing for a moment, but there is a more realistic point of view: Software developers do not want weak managers.

While the whole concept of "management" may annoy them and while they may look down upon it compared to the "purity" of software development, the geeks around you absolutely value what you do and what you do for them. First of all, you do it, not them. That’s worth something. You keep the other managers off their backs, and you filter all the noise that buzzes around the project into a concise and intelligent stream. You work the interfaces and get the developers what they need so that they can focus on what it is that they do best--creating solid software. You give moral support and remind them of the value of what they do when they hit those inevitable dips and hollows. You know that if in mid-project you left, or were transferred, or promoted, that it would bring grief to your team members . . . don’t you?

Corporations claim to be meritocracies, but anyone who has worked for a time in the real world knows that pure merit does not fuel a rise to the top. Ability and achievement are important, to be sure, but in a world in which the hierarchy narrows as you rise, other factors must play very large in the selection of those who are to be moved to the next rung. For many managers, unfortunately, a narrow focus upward is the nucleus of their existence. Their pains exist in pushing for success, nothing more than another appeal to those in power, and as they scratch higher, those upon whose shoulders they stand are too easily forgotten.

A manager who has the devotion of her people, we believe, will ultimately triumph over someone who plays the game only for herself. Developers don’t become devoted to people who view them as interchangeable parts. If your aim is solely to ascend the corporate ladder and you are looking for a method to climb higher and faster, even if it means figuring out how to squeeze the most out of your pesky developers, then we salute your indefatigability. But we really have nothing to say that can help you. For those who are looking for a better way to be effective leaders, we vigorously salute each of you because we hope that you will become the sort of person that we would someday happily choose out of any manager pool as our leader.

The real competition is not for the attention of the executive board but for the love--yes, that’s right, love--of your development staff, and for those in other teams who learn of your goodness by word of mouth. Think that this is some hallucinatory fantasy of ours? Well, maybe. The authors indeed have worked diligently for leaders whom they adored, and for whom they have even changed jobs and watched others change jobs for the same reason. The truly Great Ones thrive to this day, surrounded as ever by developers who have only a single condition on their employers--that they work for one of these Great Ones. Ask a few developers outright: Would they prefer to work for the slick, silver-tongued, aggressive, upwardly mobile managers down the hall, if it meant an instant 10 percent salary increase? If they would, then you have just discovered the metric for greatness (or the lack of it) in your company, although it is admittedly rather crude. If not 10 percent, then how about 15 percent? 20 percent? More? Wow! We’re impressed. The more it would cost to lure your people from you, the higher you are held in their esteem.

We’ve been told that this idea of teams selecting managers from a pool, The Manager Pool, is a ridiculous fantasy. It smacks of social engineering, and the "powers that be" don’t want to test the theory and risk complete corporate chaos. There are other well-documented and slickly presented professional programs out there that teach pleasant, risk-free approaches for accelerating production in the organization. That is, risk-free for those who think it’s risky to put their own hide on the line. As for those mysterious "powers that be," we are frankly suspicious of past embraces of Total Quality Management, lifestyle policies that look good on paper, corporate reengineering, automatic code generation, and we hope that the "powers" shudder at the idea of inverting a few bricks in their hierarchical pyramid.

Our approach is rather more civilized. We are not proposing "a dialectic in the capitalist boondoggle" of software development as a secret way to topple them from their peak. We just want the opportunity to find and work for leaders that help us to excel. And we want to excel by building software, and building it in a manner that makes the world a better place.

This book offers you the tools to help you become the kind of manager who would be selected even in the ugliest of managerial pools by software work teams who are autonomous in the selection of their own members. We encourage you and your company to embrace the challenge and adopt The Manager Pool (or at least the attitude implicit in the concept), where leadership staff can be traded, fired from the team, or kept in perpetuity. Consider the idea of The Manager Pool as the sincerest test. You might get the Blue Ribbon.


  1. For a more complete discussion of Software Patterns, see James O. Coplien's Software Patterns, SIGS Books and Multimedia, New York, 1996.
  2. Alexander, C. (1979). The Timeless Way of Building. New York: Oxford University Press, 247.
  3. Ibid., 311.
  4. Ibid., 347.
  5. Ibid., 304.




Abandon Ship, 215-217, 267 and Direct Action, 81
Actor Prepares, An 17, 18
Alexander, Christopher, xiv-xvii, 136, 225, 240, 246
Allegiance, 44


Backfires, 187-189, 266
and inoculation, 124
Balance, 43-45
Ball Court, 233-236, 267
Beasley, Eugene T., 223n
Beck, Kent, 115
Blowhole, 43-45, 261
Borden, Lizzie, 65
“Breaking through,” 49
Bronson, Po, 226n
Brown, W. H., 81n
Brown, W. J., 81
“Busting back,” 258-259


Campbell, Joseph, 32-33
Camus, Albert, 114
Cargo Cult, 203-205, 266
Carter, Jimmy, 59
Casual Duty, 153-155
and One by One, 136
and Trial Project, 143
Chaos, 114-115
Chopra, Deepak, 216
Cleary, Thomas, 131n
Clinton, William, 208
Cluetrain Manifesto, The, 6
Coach, 95
Coffee, 251-253
Collaboration, 135
Collective ownership, 181-182
Commitment, 5-9
Conflict, 23-26
Consensus, 167-169
Constantine, Larry, 49, 71
Containment Building, 201-202
Cooper, Alan, 134
Cop a Plea, 207-209, 266
Coplien, James O., xv
Cube, 221
Cultural Competence, 35-38, 260
and inoculation, 124
Customer management, 113-115


Decipher Discontent, 183-185, 266
Defeat, 149-151, 265
Defense de Pisser, 103-106, 263
Degradation, 28-30
Deming, W. Edwards, 6n
DeSalvo, Tina, 230n
Design Patterns: Elements of Reusable Object-Oriented Software, xiv
Direct Action, 79-83, 262-263
and Blowhole, 45
and Tribal Language, 71
Diversity, 35-38
Divide and Conquer, 171-173, 265
Documentation, 11-12
Drama, 15-18, 260
Drug testing, 103-106


Easton, Mark, 203
Economist, The, 106
Enough Rope, 191-192
Equilibrium, 43-45
Exhibitionism, 53-56, 261
Exploiting Chaos, 114
eXtreme Programming eXplained, 115, 181


“Face time,” 85
Fall on the Grenade, 211-214
and Blowhole, 45
and Direct Action, 81
Featurectomy, 197-199, 266
and Finish Line, 119
Finish Line, 117-119, 264
Formal Space, 249-250
Forty Whacks, 65-68, 261
Fuel, 251-254, 267


Gamma, Erich, xiv
Gauntlet, The, 109-111, 247, 264
Geek Channeling, 47-50, 261
Geek Space, 245-248
and Formal Space, 250
Geek Speak, 7071
Get a Guru, 89-92, 263
Good Service, 27-30
and Switzerland, 26
Gordon, Thomas, 59, 75
Gore, Albert, 246
Graham, John, 126
Grease the Wheel, 129-131
and Decipher Discontent, 184
Groups, 171-173
Guiding Hand, 3-4
and Leviathan, 14
Guru, 89-92


Hamlet, 82
Hardy, Thomas, 45
Harvey, G., 252
Heart Aroused, The, 13, 16
Helm, Richard, xiv
Herding Cats, 167-169, 265
Home Field Advantage, 93-95, 263
and Outcome Based, 87
and Passengers Push, 182
Houdini, Harry, 61
Hover Shoes, 39-41
and Blowhole, 45
Humiliation, 28-30
Humor, 74-76
Hung Tzu Ch’eng, 48


I Ching, 26
Incentives, 159-161
Inmates Are Running the Asylum, The, 134
Inoculation, 121-124, 264
Intellectual Capital, 127


Johnson, Ralph, xiv
Just Say No, 125-128
and Finish Line, 119


Lao Tzu, 64
Law of Unintended Consequences, 63
Leadership Effectiveness Training, 59, 75
Leave It to Beaver, 66
Leifer, Eric M., 93n
Leviathan, 11-14, 259-260
and Geek Channeling, 50
and Switzerland, 24
Levine, Rick, 6n
Living Space, 221-227, 267
and Formal Space, 250
Locke, Christopher, 6n
Lockheed-Martin, 147
Long, Earl, 204-205


McConnell, Steve, 67, 172, 194
Malveau, R. C., 81n
Meetings, 133-136
Melville, Herman, 12-13, 159
Metaphor, 19-21, 260
and Drama, 18
Miller, Henry, 222n
Moby Dick, 12-13, 159, 161
Mother Jones, 17
Myth of Sisyphus, 114


Nelson, Walter Henry, 176n
Neutrality, 23-26
Niemoller, Martin, 28-29


Olson, Dave, 114
One by One, 133-136, 264
One developer-one problem paradigm, 180
Organizational charts, 204-205
OTGT (Overtime Gravy Train), 98-99
Outcome Based, 85-87, 263
Overtime Detox, 97-101, 263
Ownership, 180-182


Passengers Push, 179-182, 265
Paternalism, 65-68
Pattern, xiii-xvi
Pattern language, xv
Pattern Language, A, 226, 246
Patterns form, xvi-xviii
Peer pressure, 175-178
and Divide and Conquer, 172
and Passengers Push, 182
and Tribal Language, 71
Pool selection, xviii-xxi
Power of Myth, The, 32-33
Prioritizing, 39-41
Private Space, 237-240, 267
Public Space, 241-243
collaboration, 135
Push the Customer, 113-115, 264
and Blowhole, 45
and Finish Line, 119


Rabelais, François, 74
Red Cloud, 69
Relationships, 31-34, 76
Reorganization, 204
Repetitive stress, 234
Rotten Fruit, 193-195, 247, 266


Searls, Doc, 6n
Secret Stash, 145-147
Seven Spiritual Laws of Success, The, 216
Shackleton, Ernest H., 212-213
Shameless Ignoramus, 57-60, 261
and Get a Guru, 92
and Tribal Language, 71-72
Significant Events, 163-165, 265
Smith, Jude, 35n
Social Jester, 73-76, 262
and Passengers Push, 182
and Tribal Language, 72
Software Patterns, xv
Spanish Ounce of Gold, 159-161, 265
Stanislavsky, Constantin, 17-18
Stewart, Thomas A., 127
Stimson, Cardon, 165, 249
Stories, 19-21
Strange attractor, 13
Sun Tzu, 131
Super-objective, 17-18
SWAT Team, 172
Switzerland, 23-26, 260
and Blowhole, 45


Teachings on the Art of War, 131
Temperance League, 80-81
Timeless Way of Building, The, xv
Titanic, 215
Too Clever by Half, 61-64, 261
and Tribal Language, 72
Total Commitment, 5-9, 259
and Good Service, 30
and Switzerland, 24
Train Hard, Fight Easy, 137-139, 264
Trial Project, 141-143, 264
and One by One, 136
and Train Hard, Fight Easy, 139
Tribal Language, 69-72, 262
and Geek Channeling, 50
and Get a Guru, 92
Truman, Harry S., 213


Unique Place, 229-231, 267
Urine testing, 103-106


Vacation, 255-258, 267
Vlissides, John, xiv


Weinberger, David, 6n
Whole People, 31-34, 260
and Good Service, 30
and Metaphor, 21
Whole-team approach, 62-63
Whyte, David, 13, 16


Submit Errata

More Information

Unlimited one-month access with your purchase
Free Safari Membership