em

HackNot - Extreme Programming and Agile Methods

Part of Hacknot: Essays on Software Development

Extreme Deprogramming 1

In recent weeks I’ve read two books by cult survivors. The first, “Inside Out” by Alexandra Stein2, describes her ten year embroilment in a Minneapolis political cult called “The O.” The second, “Seductive Poison” by Deborah Layton3, details the author’s involvement with the “Peoples Temple,” the religious cult lead by Jim Jones, who engineered the mass suicide of 900 of his followers in 1978.

Reading each I became aware of the similarities in the methods for control, manipulation and persuasion that both cults employed. It also occurred to me that those techniques were not just features of groups that would conform to the traditional definition of a cult, but also extended to what might be called benign cults. Think of the fierce loyalty of members of pyramid organizations such as Amway and Mary Kay; think of brands with a loyal consumer base like Apple and Harley Davidson4; and finally, think of the ardent supporters of Extreme Programming.

By examining some of the characteristic features of cults (benign and otherwise) and calling out their presence in the recently popular XP movement, I hope to throw some light on why this technical cult incites such fervor and emotion in certain members of the development community.

Drawing on the work of thought reform specialist Robert Lifton and others, consider the following characteristics of a cult, all of which are displayed by XP:

  • Sense of higher purpose
  • Loaded language
  • Creation of an exclusive community
  • Persuasive leadership
  • Revisionism
  • Aura of sacred science

Sense Of Higher Purpose

Cult members believe that they are privy to special truths and insights not known to the general community, and that it is their mission to spread this knowledge to others.

I could only laugh when I read Scott Ambler’s response5 to a letter taking issue with an article on outsourcing that he wrote for Software Development magazine. In the July 2003 issue he wrote “While it’s nice that so many Indian companies have high CMM ratings, it doesn’t reflect modern thinking about software development. CMM and Six Sigma have a tendency to lead to prescriptive, documentation-heavy processes.” These are the words of a zealot, who is so convinced of the righteousness of his beliefs that he is willing to elevate them to the status of being representative of “modern thinking about software development.” In unguarded moments, it is occasionally conceded that XP is not the answer to all software development problems, but that is certainly the attitude portrayed by many of its devotees. Spend any time reading comp.software.extreme-programming and you will not be able to help but notice the thinly veiled arrogance and elitist attitude behind the postings of many of XP’s most zealous followers. This is definitely a group of people who think they have got it, and that anyone else not similarly enthused is a laggard.

Loaded Language

Cults create a custom vocabulary for their members. New words are invented, existing words are redefined, and a jargon of trite and pat clichés is developed.

Perhaps XP’s most egregious effect on the broader software development community has been to infect communication with cutesy slogans and acronyms. No one could overlook the overuse the word “extreme” has been put to in the marketing of a host of unrelated products and concepts. The only common meaning amongst Extreme Programming, Extreme Project Management, Extreme Design and Extreme Testing is the implication of identifying a product that is sufficiently different from previous offerings to warrant purchase.

“Refactoring” has been abducted from its proper home in the algebraic texts and elevated to the status of an essential work method, which one must apply “ruthlessly.” If we consider that “rework” or “restructuring” are essentially synonyms for “refactoring”, we see that this piece of custom terminology is only dignifying the act of investing effort to correct ill-considered implementation decisions for no functional gain. In general usage, I have noticed the term being used as an even broader euphemism to disguise and minimize bug fixing and functional extension.

Particularly offensive is the frequent characterization of XP as “disciplined”. XP may satisfy the weakest definitions of the word “disciplined” in so far as there is some regularity and control in its methods. But these minor concessions to true rigor are in fact just the leftovers remaining after the elimination of particular activities from a truly disciplined development process – one that includes formal documentation and design. The abandonment of these activities is precisely where XP’s principal appeal to many lies – that there are fragments of a rigorous development process remaining after the unpleasant stuff has been cast aside is hardly sufficient basis upon which to claim that the overall work pattern exhibits discipline – unless one considers the determined pursuit of the path of least resistance to evidence discipline.

The XP jargon serves the same purpose as it does in any cult, to elevate the mundane to the significant through relabelling, and to misdirect attention away from failings and inconsistencies in the cult’s value system. It is a shame that the XP community did not apply its own YAGNI (You Ain’t Gonna Need It) principle to the invention of such novel terminology.

Creation Of An Exclusive Community

A cult provides a surrogate family for its members, who feel somehow separated and at odds with mainstream society.

Cults are a refuge for the uncertain. For those feeling lost or without direction, the faux certainty of a cult provides welcome relief. Software development is a field full of uncertainty. The increasing societal reliance upon software and the attendant but conflicting requirements for speedy and reliable development, has outpaced our ability to learn better ways to do our work. Faced with this unsatisfactory situation and desperate for a solution, the development community is vulnerable to the claims and promises made by XP. The fact that there is a community of enthusiastic proponents behind XP serves only to enhance its credibility via the principle of social proof6. In truth, the presence of such a community only evidences the widespread confusion about software development methods, coupled with the hope that there is some answer that doesn’t entail unpleasant activities such as documentation.

Persuasive Leadership

Central to almost all cults is the founding member, a figure who through the strength of their own conviction is able to attract others to their cause.

The leaders of the XP movement are three members of the C3 project where XP was piloted – Kent Beck, Ron Jeffries and Ward Cunningham – and to a lesser extent the industry figures who have adopted it as their personal cause – Scott Ambler and Martin Fowler being amongst these. These people have generated an impressive amount of literature which forms the basis for the ever growing XP canon. They also serve as the XP community’s ultimate arbiters of policy and direction. Reading the comp.software.extreme-programming newsgroup I notice people continually directing questions about their own interpretations of the XP doctrine to these central figures, seeking their approval and the authority of their advice. That there is a need for personal consultation in addition to the information provided by the large amount of literature on XP speaks of the imprecise and variable definition of the subtleties of XP practice. That knowledge of what is and isn’t OK is seen to be held by a central authority and is not in the hands of the practitioners themselves, echoes the authoritarian distribution of sacred knowledge that is present in most cults.

Revisionism

Cults often craft alternative interpretations of world events, both present and historical, that serve to reinforce their belief system.

There are a number of examples of revisionism in XP. The most blatant concern the C3 project – the original breeding ground for XP. Proponents of XP repeatedly use this project as their poster child, the tacit claim being that its success is evidence of the validity of XP. However the reality is that the C3 project was a failure – ultimately being abandoned by the project sponsor and replaced with an off-the-shelf solution7. XP advocates have chosen to cast this failure as a success, by carefully defining the criteria for success that they claim is relevant. It is typical cult behavior to interpret real world events in a light that confirms existing beliefs, and to deny contrary evidence as being inauthentic.

One of the advantages of having a central authority is the ability to reconceive fundamental beliefs when necessary. The change in the attitude of the XP “inner circle” with regard to the production of documentation is an example of this. In its initial conception, documentation was regarded as unnecessary. In the light of real world experiences with XP, this stance softened to include the production of documentation “if you are required to.” More recently, the philosophy has been stated as “if it’s valuable to you, do it.” Some would dismiss this as a result of XP’s infancy, claiming that it is still being developed and refined; but I believe these shifts in position are the thought reformer’s attempts to incorporate unflattering real world experience into their original ideation. Whatever real practitioner’s experiences are, we can be sure that the primacy of XP doctrine will remain.

Aura Of Sacred Science

Which implies that the laws and tenets of the cult are beyond question.

Central to XP is the notion of the 12 core practices. These technical equivalents of the Ten Commandments are considered interdependent and so the removal of any one of them is likely to cause the collapse of the whole. This all-or-nothing thinking is typical of cults. Members must display total dedication to the cult and its objectives, or they are labeled impure and expelled from the community. This discourages members from questioning the cult’s fundamental beliefs.

In the case of XP, the organizational circumstances required to perform all the core practices are so particular that it is doubtful if more than a handful of companies could ever host an authentic XP project. Therefore practitioners are forced to perform partial implementations of XP. If they are unsuccessful, then failure is attributed to the impurity of their implementation rather than any failing or infeasibility of XP itself. The quest for individual purity is a feature common to many cults, as is the contrivance of circumstances that render it ultimately unachievable.

Much is made of the “humanity” of the methodology, the transition from “journeyman” to “master”, and the focus upon individual qualities and contributions. Consideration of these softer, cultural aspects of XP has devolved into the sort of pseudoscience we often find in new age cults centered on the notion of “personal power” and “personal growth”. To quote one zealot “XP is a culture, not a method.”8 The elevation of a new and unproven methodology to the philosophical status of a Zen-like belief system demonstrates the skewed perspective that typifies cult mentality.

Conclusion

Whether you choose to label XP a cult is not as important as whether you recognize that it displays cult-like attributes. I believe that the psychological and social phenomenon underlying these six characteristics account in no small part for the current popularity that XP enjoys. I also believe that they point to its future.

Cults tend to have a very limited life. The hype and fervor can only sustain the devotion of the members for so long, and eventually they will look to other sources for inspiration – those leaving a cult are frequently drawn into another within a short time.

I believe that XP will eventually lose its luster and fall into disrepute like so many other religious, commercial and technical cults of the past. Many of the current adherents will cast about for a new cause to follow, and no doubt the marketing departments of the technical book publishers and software vendors will be only too happy to provide them with a new subject upon which to focus their devotion. Meanwhile, software projects will continue to fail or succeed with the same frequency as always, as our industry continues its search for a panacea to the ills of software development.

New Methodologies or New Age Methodologies? 9

I first encountered the coincidence of the aesthetic and the technical in a secondary school mathematics class. After leading the class through an algebraic proof, my teacher said “You have to admit there’s a certain beauty to that.” As I recall, he was met by a room of blank stares, one of which was my own. I remember thinking “You sad, sad man.” I really couldn’t see how a mathematical proof could be called “beautiful”. Beauty was an attribute reserved for the arts – a song could be beautiful, a painting could be beautiful, but a mathematical proof might at best be called “ingenious.”

It wasn’t until some years later at University, while studying data structures and algorithms that I would come to some appreciation of what my mathematics teacher had meant. An appreciation of certain algorithms would leave me with a smile on my face, and an ineffable feeling of satisfaction. I believe that to appreciate the beauty of something technical first requires the observer to care a lot about the subject at hand, and that what we experience has something to do with a sense of admiration for the mind that produced the thing, rather than the thing itself.

That it is possible to appreciate the technical in an aesthetic way is a realization that I suspect comes to many people after spending long enough in a particular technical field. But that aesthetic is a quality of an existing artifact, not a basis for its production. The sense of “rightness” that we associate with an elegant solution to a problem is the end result of a rather less romantic, technical struggle. It is not the starting point for that struggle, but rather a flag that indicates that we have arrived at a good resolution.

The New Age Methodologies

One of the more disturbing characteristics of the New Methodologies of software development is the tendency to impose a new aesthetic upon existing knowledge, and then interpret that aesthetic as evidence that something new has been discovered. Hence, we find the literature of the New Methodologies littered with references to Zen philosophy, craftsmanship, martial arts and personal empowerment. This is the stuff of pseudo-science and mysticism. By indulging in this sort of “discovery by metaphor,” we risk descending into a stasis of vague, self-referential navel gazing that characterizes the delusional New Age movement.

In the following sections I look at a number of the software development metaphors that recent authors have proposed as a means of gaining insight into the software development process.

Personal Empowerment

The New Methodologies purport to be more focused on people than on process. This is often construed as empowering the programmers against a harsh and dictatorial management. The New Methodologies have values and principles at their foundation, on an equal footing with actual techniques and practices. Commonly touted values are communication, simplicity, feedback, courage and humility. No doubt these are worthwhile values, not only in software development but in practically every other field of human endeavor. So why would we chose to focus on these values particularly, and their relationship to software development? Perhaps the biggest effect of highlighting this arbitrary selection of values is to add a certain faux credibility to a methodology by associating it with noble concepts.

The irony of the “empowerment” message is that the vagueness of this values-based approach actually has the opposite effect – it disempowers the programmer. The power is placed instead in the hands of the methodologists, who must be consulted as to what the appropriate interpretation of these values is, in the situations the programmers actually encounter in the field. These spokesmen have become moral arbiters. A more precise and objective methodological foundation would empower individuals to unambiguously interpret the methodology’s recommendations in their local environment, without the need to continuously seek clarification from the methodologists.

For more rational discussion of the predilections and working habits of software developers see:

  • “The Psychology of Computer Programming” by Gerald Weinberg
  • “Peopleware” by Tom DeMarco and Timothy Lister
  • “Constantine on Peopleware” by Larry Constantine
  • “Understanding the Professional Programmer” by Gerald Weinberg

Eastern Mysticism

Nowhere do the New Methodologies and the New Age movement intersect to more egregious effect than in the area of Zen philosophy. In an attempt to elevate the ordinary to the profound, or to disguise self-contradiction as sagacity, the New Methodologists will often invoke the inexplicable wisdom of Zen.

In the new edition of “Agile Software Development”, Alistair Cockburn offers us this:

“It is paradoxical, because it is not the case, and at the same time it is very much the case, that software development is mathematical … engineering … craft … a mystical act of creation”.

Worse yet, this obfuscating nonsense is later followed by:

“The trouble with using engineering as a reference is that we, as a community, don’t know what that means.”

So the “engineering” metaphor is unacceptably difficult to understand, but koan-like homilies are OK?

Cockburn then introduces his Shu-Ha-Ri model of software development practice. Shu, Ha and Ri are the three levels of practice in Aikido, and roughly translate into learn, detach and transcend. In drawing this obtuse metaphor, Cockburn manages to simultaneously insult the intelligence of his readers and the martial arts tradition whose authenticity he is trying to co-opt. Much is made of the fact that software developers can be considered to pass through successive stages of facility that correspond to Shu, Ha and Ri. Nothing is made of the fact that the same analogy can be drawn with every other occupation whose practitioners grow in expertise over time.

One keeps waiting for the admission that all this armchair philosophizing is just self-deprecating jest, but it seems it is not going to be forthcoming. If you need a laugh, I’d encourage you read Kent Beck’s message to a young extremist10 and the comments that follow it. A greater pile of pseudo-intellectual backslapping you will not find anywhere outside of the self-congratulatory annals of the New Age movement.

Craftsmanship

The portrayal of “software development as craft” reached its most irksome zenith in Pete McBreen’s loathsome book “Software Craftsmanship”11. The book presents a false dichotomy between engineering and craft. Engineering is mischaracterized as a soul-less and impersonal undertaking that ignores the contribution of, and variations between, individuals. However craftsmanship values the individual and nurtures their development through apprenticeship-like relationships with other practitioners.

McBreen makes the profound observation: “… large methodologies and formal structures don’t write software; people do.” Who’d have thought? I rather thought these structures were there to support the people in their efforts, not to supplant them. But apparently the Big M Methodologists are conspiring to eliminate the human contribution altogether and our only chance to save our jobs and our identities is to embrace our “craft” and our role in its development.

I’m sure many developers like to think of themselves as craftsmen – it strokes their egos and elevates their self-perceived status. However the notion of a craft is usually reserved for activities where artifacts are produced through manual skill and dexterity e.g. carpentry, painting, sculpture. In common usage you will also find it applied to certain intellectual artifacts (as in “well crafted prose”) but not those artifacts of a more technical origin, of which software is surely one (we don’t speak of “well crafted formulae”)

To liken software developers to craftsmen may be superficially appealing, but it represents a retreat into the vague and inscrutable domain of the New Age theorist.

This Is Engineering

Engineering is the use of scientific knowledge to solve practical problems. It is characterized by activities such as planning and construction. Engineers maintain such values as precision, realism and integrity. Taking an engineering-based approach to software development in no way denies the significant influence that individual abilities and social dynamics exert over the outcomes we produce.

I believe engineering remains a suitable basis upon which we can make concrete advances in software development practices. The kind of New Age humanism we are seeing incorporated into the New Methodologies only encourages endless philosophizing, metaphysical thinking and wasted effort spent in the exploration of non-falsifiable premises.

Follow The Money

If the New Methodologies continue to follow the examples of their New Age counterparts, it can only be a matter of time before they begin to employ some of the same merchandising tactics. Only half in jest, I contend that before too long we will see the following items available for your convenient online purchase:

  • Tapes and CDs of lectures given by notable New Methodologists, that you can listen to in your car on the way to work. Titles may include “The Path To Agility” and “Power Programming”.
  • Office decorations in the mould of the Successories products. Inspirational plaques with panoramic landscapes and themes like courage, simplicity, humility etc. Matching mouse pads, mugs and badges.
  • The “Agile Thought of the Day” email services
  • Hokey accessories like diaries and calendars featuring slogans like “You Ain’t Gonna Need It” and “Do The Simplest Thing That Could Possibly Work”. The XP Programmer’s cube12 may be an early prototype.

Finally, let me leave you with a Zen parable. Make of it what you will:

Bazen and an Engineer were out walking together. Bazen turned to the Engineer and said, “Tell me Engineer, what is the sound of one hand clapping?” The Engineer, swatting at the air near one ear, replied “It’s sort of a ‘wooshing’ noise, isn’t it?” At this, Bazen was enlightened.

Rhetorical AntiPatterns in XP 13

Over the past few years, I’ve spent more time in consideration of XP and its followers than is in the best interests of one’s mental health. My preoccupation with it springs from my broader interest in skepticism. It’s fascinating to watch the same forces that drive cults, pseudo-science and other popular delusions at work in one’s own profession. It’s like driving past a road accident. It’s tragic and disturbing, but so entrancing that you just can’t look away.

One of the aspects of XP that is particularly intriguing is the way that certain rhetorical devices are used repeatedly to prop up the XP belief system in the face an uncooperative reality.

This post describes the four main rhetorical devices that XPers use to influence their audience and each other. Once you see how it’s done, you’ll find yourself able to “talk XP” like a native.

The four techniques are:

  • Adopt A Tone Of Authority And Eschew Equivocation
  • Make Bold Assertions And Broad Generalizations
  • Use Evidence Whose Veracity Can Not Be Challenged
  • Create Slogans And Neologisms

Adopt A Tone Of Authority And Eschew Equivocation

No matter what questions you might have, there is someone out there that is willing to sell you the answers. And although the vendors come in many different forms they have one characteristic in common – they all appear absolutely sincere and absolutely sure of themselves. So must you be if you are to talk like a true XPer.

Fortunately, the impression of authority is easily created with some linguistic sleight of hand:

  • Never qualify your statements or concede error. If you say “I don’t think that is true” nobody will notice. But if you say “That is absolutely false” you can capture people’s interest and attention.
  • Intimate that you are speaking on behalf of others. For example, the statement “Software developers don’t work that way” is more compelling than the statement “I don’t work that way.” Stating that “Everybody knows X” is more impressive than stating “I know X.”

Exercise some restraint with these techniques. It’s easy to go too far and sound like a born-again prophet. You will find it useful to temper your pontifications with the occasional self-deprecatory statement, just to make it clear to your audience that although you know you are very wise, you don’t think you’re the Messiah.

Another way of elevating your own perceived authority is to denigrate others. For example, those not enamored of pair programming may be accused of being socially inept or sociopathic. More recently, we have seen attempts to attribute a distaste for pair programming to genetic disorders such as autism and Asperger’s syndrome. Statements so personal are delightfully controversial, and can also be used to goad detractors into overly emotive responses, which can be interpreted as further evidence of mental instability. Applied frequently enough, such pathologizing will discourage your detractors from making public criticisms, knowing that they will be virtually waving their “freak flag” for all the world to see.

Finally, boost your own credibility by borrowing it from elsewhere. Make occasional references to:

  • Eastern philosophies and spiritual traditions
  • Movies, literature and personalities from pop culture
  • Advanced mathematics and physics, particularly chaos theory and quantum mechanics
  • Political ideologies

Make Bold Assertions And Broad Generalizations

XP rhetoric is characterized by broad and sweeping generalizations about software development practice, projects and developers. A classic example is the following, from Kent Beck:

Unacknowledged fear is the source of all software project failures.14

It takes a special kind of person to make such claims – specifically, one that is breathtakingly arrogant. If this arrogance doesn’t come naturally to you, then you will have to affect it. The more spectacular and entertaining your statements, the better the chance that they will be turned into a sound bite or quoted by a journalist. The media loves attention grabbing one-liners and there is little you can say that is so ridiculous that the determined reader will not find some way to interpret it as both meaningful and insightful.

Do not let an absence of supporting evidence constrain your imagination. If detractors point out exceptions to your generalizations, simply dismiss those exceptions as being so atypical or statistically insignificant as to not warrant revision of an otherwise useful rule of thumb.

In argument, coupling these generalizations with baseless assertions is an effective “one-two” punch to your opponent’s frontal lobes. If they should be rendered speechless at the audacity of your statements, seize the opportunity to change the subject or offer some non-sequitur, so that they will not have the opportunity to challenge you.

Most importantly, remember that the credibility of your propositions rests almost exclusively on your ability to deliver them with absolute conviction. The software development community are a gullible lot, and provided that you sound like you know what you’re talking about, a great number of them will simply assume that you’ve got the facts to back it up. For those unencumbered by integrity, this is the ideal flock to lead out of the programmatic wilderness, if only you can make the cattle-call compelling enough.

To get you started, here are some bold assertions and baseless generalizations that are anti-XP in nature. Feel free to use them in your next exchange with an XPer.

  • It is inevitable that XP will fade into technical obscurity, just like every other fad the software industry has witnessed in the last thirty years.
  • The fervor with which XPers cling to their codecentric methodology betrays the underlying fear which drives them: the fear that if they should ever stop typing someone might realize that coding is their only skill. In a modern business context the ability to code is useless if not accompanied, in equal or greater measure, by the ability to perform a whole host of non-coding activities that XP does not even address.
  • Extreme programming is not about programming. It is about the attempts of a small group of attention-seeking individuals to make their mark on the computing landscape. • The irony of Extreme Programming is that to make it work in the real world, you have to moderate the “extremeness” to such an extent that you’re left with just “programming.”

Use Evidence Whose Veracity Can Not Be Challenged

The software development community has a very low evidentiary standard – somewhere approaching zero. In other words, personal observations and testimonials are the only corroboration that most will require for any statement you might make. Empirical software engineering is not a popular field and the task of gathering empirical data sounds altogether like too much hard work for most to be bothered with it. All the numbers and statistics that it generates make really boring reading. Additionally, it takes time to conduct experiments, and who has that sort of time when you’re busy “riding the wave” of the latest technology fad?

These factors are a gift to you, the burgeoning XP orator. With suitably contrived “anecdotal evidence” you can justify any claim you might make, no matter how preposterous. Whether such evidence has any basis in fact is almost entirely irrelevant. Anecdotal evidence is qualitative in nature, which lends itself readily to exaggeration and confabulation. You can create anecdotal statistics, safe in the knowledge that nobody has any better information with which to challenge you. Here’s an example from Robert Martin:

We find that only one in twenty programmers dislike pairing so much that they refuse to continue after trying it. About one in ten programmers start out being strongly resistant to the idea, but after trying for a couple of weeks about half of them find that pairing helps them.15

If anyone does try to challenge your statistics, just ask them why they are so hung up on numbers, and suggest that an emphasis upon quantification in software development is unreasonable and impractical.

If the purported evidence originates from your own experiences, prefix it with “in my experience” and claim “I’ve seen it with my own eyes.” Who could doubt that? If you want evidence to have come from someone else, to create the impression of independence, remember that you can always get the answers you want by asking the right questions of the right people.

Create Slogans And Neologisms

If you’ve ever wondered why the XP lexicon contains so many trite catch phrases like “embrace change” and cutesy terms like “planning game” and “YAGNI”, then you’ve hit upon two of the most important features of the vernacular – slogans and neologisms.

Slogans are a frequently used marketing device. They’re like the “hook” in a pop song – they are music to the ears of the masses. As an added bonus, they lend themselves to being parroted off dogmatically – which will discourage people from thinking (critically or otherwise) about the validity of the propositions they embody. XP slogans are the rhetorical equivalent of the pre-prepared meals that TV cooking show hosts introduce with the phrase “here’s one I made earlier.”

To get you started, here are a few anti-XP slogans you might like to put on a t-shirt or poster:

  • Pair programming – for those with only half a brain
  • eXtreme Propaganda not welcome here
  • Embrace Change (You’re Gonna Need It after you get fired)
  • IfXPIsSoGreatWhyCan’tTheyFindTheSpaceBar?

Neologisms are a trademark of many methodologies. By creating new terms you also create the impression of invention; of having discovered or created something so novel that no existing term adequately describes it. Conveniently then, neologisms allow you to take old knowledge, give it a new name, and then portray it as being something new. What’s more, if you created the term, then you have a monopoly over its definition, which you are free to change from time to time as suits your purpose. You can even furnish common terms like “success” and “simple” with methodology-specific definitions, if this is what it takes to preserve the truth of some rather brash statements you made earlier. Do not be hampered by the bug-bear of consistency. Feel free to develop conflicting definitions of terms, giving you the freedom to later invoke whatever definition is most convenient for the situation you’re in. If anyone should highlight your self-contradiction, simply excuse it as evidence of a deeper wisdom that defies even your complete understanding.

A Catechism

To illustrate how these techniques can be used in combination, I offer you the following dialog that I may or may not have had recently (hey, it’s anecdotal evidence – how are you going to challenge me?) with a hard-core XPer. I chose to abandon my usual skeptical mode of argument and get “down and dirty” with some XP lingo. I encourage you to try it sometime. It’s quite liberating to be free of the constraints of logic, and the burden of proof.

XPer
Hey Ed, want to do some pair programming with me?
Ed
No thanks - pair programming isn’t for me.
XPer
Have you tried it?
Ed
Briefly, but I disliked it - which wasn’t surprising. It’s quite at odds with my personality.
XPer
How long did you try it for?
Ed
Oh - about four days or so.
XPer
(laughing) That’s not nearly long enough. And you’ve got to make sure you’re doing it right, otherwise it won’t work.
Ed
No … really. No amount of persistence is going to change the situation. I know enough about my own nature to say that with some confidence.
XPer
But why not try it again? What are you afraid of?
Ed
[switching to XP lingo] I’m afraid of ending up in a state of total cognitive surrender, like yourself and other similarly disillusioned XP zealots. Anyway – why do you need to program with someone else? Aren’t you good enough to work by yourself?
XPer
[taken aback] It’s not about “good enough”, it’s about “better”. I’m more productive when I work with someone else.
Ed
So you claim. If I claimed to be more productive with a whiskey and soda by my side, would that warrant charging up a bottle of Jack Daniels to the project? Playing around with novel work methods at the customer’s expense is professionally irresponsible.
XPer
But pair programming works! I’ve experienced it for myself!
Ed
No, what you’ve experienced is having a nice time with a buddy. Then you justified it to yourself by claiming a productivity improvement. People see what they want to see.
XPer
I don’t think you can comment – you haven’t really tried pair programming.
Ed
Or to put it another way – I’m not the slave to technical fashion that you are – which actually gives me a more objective viewpoint from which to comment. Pair programming is a fantasy - there is simply no evidence that it works. Those who think it does are kidding themselves.
XPer
How can you say that? There was this university study that demonstrated experimentally that it works!
Ed
Are you talking about the study by Laurie Williams at the University of Utah?
XPer
Yeah – that’s the one.
Ed
Tell me – have you read William’s thesis?
XPer
Well – no, but I’ve read about it.
Ed
So I can’t comment on pair programming because I haven’t really tried it, but you can comment on experiments that you haven’t even read.
XPer
Look – I may not have read the details, but I know what it proved.
Ed
What it proved is that it’s easy to do bad experiments, and that many software developers like yourself are gullible enough to believe anything they hear, so long as it fits in with their preconceptions. If you really knew about pair programming, you’d already know that the Williams experiment proves absolutely nothing.
XPer
I’ve paired with plenty of developers in the past, but nobody got upset about it like you. Have you got some kind of problem?
Ed
If you think that others should necessarily have the same preferences as you, then I’d suggest it’s you that’s got the problem. I’m happy for you to pair program if you want, but I must decline the offer to participate in your hallucination.
XPer
[shaking head] Ed, you’ve got to learn to “embrace change”. The whole XP thing is taking off – “agile” is the way software development is gonna be from now on. Get on board or step aside.
Ed
“Change imposed is changed opposed.”
XPer
How do you mean?
Ed
For one so agile, you’re a bit slow on the pick-up. In this context, it means that if you try and force people to work a way they don’t want to, then they’ll fight back.
XPer
I don’t hear anyone fighting against XP.
Ed
Then where have you been for the last five minutes? You just demonstrated my point – people hear what they want to hear.
Ed
Ok, maybe some folks don’t get it, but there are plenty of people who do, and who are achieving success. At least as many people have tried XP and failed. Some of them go on to claim success anyway, because admitting to failure would be too embarrassing. Most of them just say nothing and hope nobody notices their stuff-up. If you think the success-stories you read about in the media are representative, you’re kidding yourself. The real story is very, very different. “Success has many fathers, but failure is an orphan.”
XPer
OK, maybe there’s some truth to that. But you can’t be saying that all these XP proponents are lying?
Ed
No – not all of them, but some of them are, and some of them are exaggerating. The rest are probably what we call “pious frauds” - that is, they genuinely believe what they’re saying, but are really misconstruing the influence of XP on their projects. It’s easy to do if you play down the negatives and emphasize the positives.
XPer
Say – didn’t you tell me once that you’re a skeptic? Shouldn’t a skeptic keep an open mind?
Ed
Yes, but not so open that their brains fall out.

The Deflowering of a Pair Programming Virgin 16

In your readings of the voluminous XP canon, you will no doubt have encountered mention of the practice of Pair Programming17. If, like me, you are of a solitary disposition, you will have found yourself thinking – nice idea, but not for me.

Many of us are attracted to software development as a career because we enjoy the experience of solitary problem solving. We relish those times when we are “in the zone” – where our locus of concern narrows to exclude everything but ourselves, the keyboard and the problem at hand. This state can produce a feeling of mild euphoria, and gives us a place of retreat from the worries and concerns of our immediate environment.

The practice of Pair Programming puts an end to all of this. The problem solving medium moves from an interior dialogue to an exterior one. The silence we traditionally associate with deep thought and focused effort is replaced with the interaction and debate we more usually expect from a meeting or brainstorming session.

It was with some trepidation then that I recently accepted an offer from a colleague to engage in some Pair Programming as a way of extending my knowledge of certain subsystems of our application in which he had a greater degree of involvement than myself. The activity lasted about four days – long enough to complete the implementation and testing of a minor system feature in its entirety. The experience was an interesting one, but on the whole, not one that I’d care to repeat with any regularity.

Pair Programming studies so far conducted have tended to originate from academic environments, and so focus on novice-novice pairings amongst students. It is not clear that their findings translate into a commercial programming context staffed by more mature professionals. By contrast, myself and the colleague I paired with have been doing whatever it is that we do for 10+ years each. In the period described herein, we sat together for approximately six hours on each day, using the same person’s computer each time.

Following is a point-form summary of my experiences over this period, both positive and negative.

Positives

  • When pairing, one programmer keeps the other from goofing off and wasting time web surfing etc.
  • You tend to be more diligent in the construction of unit tests and more careful in general when you know that someone is watching you and looking for error. Also, as a matter of professional pride, you don’t want to be seen to be hacking by a colleague.
  • The quality of code produced is marginally better than I would achieve at a first cut when coding individually.
  • When two people have participated in the construction process, familiarity with the code is spread further amongst the team members which mitigates the dependence upon any individual. If there is no external documentation, it may be more efficient to acquire familiarity with a piece of code on this basis, than by the alternative – reverse engineering.
  • There is the opportunity to pick up tricks and shortcuts from watching someone else go about the arcana of their job (e.g. learning to use IDE features that you were previously unaware of).
  • Mistakes are picked up more quickly due to the overseeing of one’s partner.

Negatives

  • The constant interaction is very tiring. Most days I went home absolutely exhausted from the enervating effect of continuous dialog, and frequently with a headache.
  • There is a lot of noise produced, which tends to disturb those in the surrounding area. A room full of pair programmers, as advocated by XP, would be very noisy indeed.
  • There are numerous ergonomic problems when two people share a computer. My colleague prefers a conventional keyboard with international settings activated (he is bilingual), a trackball and a medium screen resolution. I prefer a split keyboard, no extended character set capability, a wheelie mouse and a slightly higher screen resolution. We had to swap hardware whenever we “changed drivers,” which was annoying. Had our preferences in screen resolution not been similar, working from the one VDU could have been impossible (for example, if one of us had low vision).
  • There is a lot of “pair pressure” created from having someone watching every character you type. It tends to produce a self-consciousness that is inhibiting and constitutes a low-level and constant stressor.
  • There is a tendency to feel constantly under time pressure when typing, because someone is waiting for your every keystroke. This produces a certain degree of “hurry up” sickness, which discourages any delay in doing more typing, such as that produced by thoughtful consideration of design issues.
  • Groupthink can occur, even when there are only two people in the group. When you are working so closely with another, you are very wary of argument or disagreement, lest it sour the working relationship. Therefore people tend to agree too readily with one another, and seek compromise too quickly. Whoever chimes in first with a suggestion is likely to go unopposed.
  • Time spent away from one’s pair partner tends to be non-productive as your thoughts are dominated by the task the pair is currently tackling. This makes it difficult to effectively interleave other tasks with an extended Pair Programming session.
  • Both myself and my colleague concede that we work in a different way when pairing than when working individually. Alone, our work patterns tends to consist of short bursts of productivity, separated by periods of mental slouching, by way of recuperation and cogitation. When pairing, those intermittent rest breaks are removed for fear of hindering someone else’s progress, and because the low level details of different people’s work habits will be unlikely to exactly coincide.

Conclusions

From this brief experience in Pair Programming it seems clear to me that the appeal (and therefore success) of the practice is likely to vary significantly between individuals. More gregarious programmers may enjoy the conversation and teaming effects, whereas more introverted programmers will find the constant interaction draining.

I am particularly interested to note that reports of Pair Programming experiences commonly available through the media tend to have a positive reporting bias. Experience reports of the form “we tried pair programming and we loved it” are not difficult to come by18 (which is not to say they are significant in number, but simply that a few studies are very frequently cited), but anecdotes that end “… and then he resigned because he couldn’t bear the constant pair programming” are not as readily available.

I don’t believe my take on Pair Programming is likely to be singular. My personality type and communication preferences are not at all uncommon amongst developers. In Myers-Briggs terms I am an ISTJ19, which is the most common personality type in the IT industry. I believe that many developers will find Pair Programming to be a difficult and ultimately unsustainable work practice – one that removes from their work day some of the basic elements that first attracted them to their occupation.

For a pairing of mature developers, I believe the effect on code quality is vastly overstated amongst the XP community. That there is some marginal improvement in the quality of the code when first cut seems clear. That this improvement justifies the investment of effort required to produce it, or that it could not be obtained more efficiently through regular code review techniques, is not at all clear.

Finally, I believe that Pair Programming is a very inefficient way to share knowledge amongst team members. The total man hours invested in doubling up can result in at best two people being familiar with the code being worked on. A good design document could guide an arbitrary number of future developers to an equivalently detailed understanding of the code, saving the expense of continual, unassisted reverse engineering on their parts.

Addendum

Shortly after posting this, a reader asked for the basis of my statement that ISTJ is the most common personality type in the IT industry. The findings of two large studies are relevant here, both of which I found referenced in “Professional Software Development”, Steve McConnell, Addison Wesley, 2004, p63:

  • “Effective Project Teams: A Dilemma, a Model, a Solution”, Rob Thomsett,

American Programmer, July-August 1990, pp.25-35

  • “The DP Psyche”, Michael L. Lyons, Datamation, August 15, 1985, pp. 103-109

McConnell cites these two studies as finding the most common personality type for software developers to be ISTJ. My statement generalizes this conclusion to the entire IT industry, which is obviously unwarranted.

McConnell cites further studies from Thomsett, Lyons, Bostrom and Kaiser as finding that ISTJs comprise 25-40 percent of all software developers.

XP and ESP: The Truth is Out There! 20

“Eclipses occur, and savages are frightened. The medicine men wave wands – the sun is cured – they did it.” – Charles Fort21

People have a vast capacity for self-deception. Even members of the scientific community, from whom we expect objectivity, can unwittingly allow their personal beliefs and preconceptions to color their interpretation of data. Professional ambition and wishful thinking can turn their stance from one of neutral observance into passionate adherence to a position, sustained by willful ignorance of contrary evidence. Such attitudes are common amongst the ranks of pseudo-scientists and paranormal researchers. Enthusiasts in this domain reward these ersatz scientists by buying their books and journals in numbers proportionate to the impressiveness of the alleged experimental findings. In doing so, they become complicit in their own deception.

Many of these enthusiasts labor under the misimpression that the existence of ESP, PK and other paranormal phenomena has been “proved” by creditable scientists. Many of the researchers are similarly deceived.

Curiously, we may be seeing exactly the same effects currently at work in the software development community with regard to XP. If there is sufficient desire to find “evidence” favorable to XP, it will be found. If there is sufficient reward for publication of XP success stories, they will be published. The belief that XP has been “proved” in the field can develop, if there is sufficient desire to believe it. And if sustaining that belief makes it necessary to ignore conflicting evidence and censor stories of failure, then that will also occur.

Be it XP trials or ESP experiments, there are two sorts of bias that make it possible to find significance where there is none, and sustain false belief. This post examines how these biases manifest in both domains.

Positive Outcome Bias: Embrace Change Or Exaggerate Chance?

Positive outcome bias is defined as:

The tendency of researchers and journals to publish research with positive outcomes much more frequently than research with negative outcomes.22

Suppose 100 researchers conduct an experiment in ESP. Each professor chooses a single subject who believes they have ESP and asks them to “sense” a series of randomly chosen Zener cards being “sent” to them by the person who selects the cards. Suppose that in 50% of these experiments, the subject achieves an accuracy greater than that which could be attributed to chance alone. The 50 researchers conducting those experiments are intrigued, and decide to conduct a further round of tests with the same subject. The other 50 researchers, knowing that failed attempts to detect ESP are unlikely to get them published, abandon their experiments.

In the next round of experiments, the same pattern occurs, and 25 more researchers give up. Eventually, all the researchers give up, but not before one has witnessed his subject beat chance in 6 or 7 consecutive experiments - which is quite a spectacular result! Deciding to neglect the final experiment that caused him to stop (figuring the subject was probably tired, anyway) the researcher writes up his results and sends them to the editor of the Journal of Parapsychology, in which they are published.

Consider the deception which results:

  • The PSI research community’s pro-ESP bias has been further confirmed by their receipt of this latest research evidence
  • The readers of the Journal of Parapsychology are impressed with the evidence, and any preexisting belief in ESP is further cemented.
  • Other researchers, perhaps even some outside the PSI community, conclude “Maybe there’s really something to this ESP stuff after all” and decide to conduct their own experiments in ESP, thereby propagating the effect into another round of investigations.

Note that neither the researcher who was published, the research community, nor any of the readers of the Journal of Parapsychology ever become aware of the 99 experiments that were abandoned because they were deemed unpublishable. Taken in isolation, the published result may be impressive. But taken in the context of the other 99 experiments that have silently failed, the published result may simply be an outlier whose occurrence was actually quite likely.

The following factors contribute to positive outcome bias:

  1. Researchers who conduct uncontrolled experiments
  2. Researchers who self-censor negative results
  3. Researchers who can justify to themselves the imposition of optional starting and stopping conditions.
  4. A publication environment that favors success stories

All three of these are features of the environment in which the software development community examines and reports on your favorite methodology and mine, XP:

  1. XP is often trialed on a single project, on a non-comparative basis (controlled experimentation would be prohibitively expensive).
  2. When an XP project fails, it will probably fail quietly. Companies and individuals have reputations to protect.
  3. In a series of XP-related experiences, initial negative experiences are dismissed as “teething trouble”. For an example, see Laurie William’s pair programming experiment. Her dismissal of the last of four data sets, and devaluing of the first of those four data sets, is a good example of “optional starting and stopping conditions.”
  4. There can be no doubt that the IT media just loves those “XP saves the day” stories. Success stories sell magazines.

In such an environment, XP enthusiasts will declare “Wow, everywhere you look, XP is succeeding” – which is true. But it’s in the places that you haven’t looked that the real story lies.

Confirmation Bias

Confirmation bias is defined as:

The tendency to notice and to look for what confirms one’s beliefs, and to ignore, not look for, or undervalue the relevance of what contradicts one’s beliefs.

When it is pointed out to PSI researchers who claim to have successfully demonstrated ESP, that hundreds of non-PSI researchers have tried to replicate their results and failed, they sometimes attribute this to the ostensible influence that the attitude of both experimenter and subject can have over the results. An experimenter who is hostile towards the concept of ESP, they claim, can exert a negative influence over the results, thereby counteracting any positive ESP effects that may be present. This is one of the many “outs” PSI researchers have developed that enable them to attribute negative results to extraneous causes, and preserve only the data that is favorable to their preferred hypotheses.

We see exactly the same thing happening in the XP community’s evaluation of experience reports from the field.

When presented with a claim of success using XP, the community accepts it without challenge, for it is a welcome confirmation of pre-existing beliefs. However, a claim that XP has failed is an unwelcome affront to their personal convictions. So these claims are scrutinized until an “out” is found - some extraneous factor to which the blame for failure can be assigned. If all else fails, one can claim, as PSI researchers are wont to do, that the attitude of the participants is to blame for the failure.

To illustrate, consider the tabulation below of the four types of experience reports that the XP community can be presented with. The columns represent the two basic modes of XP usage – full and partial. Either you’re doing all the XP practices or you’re only doing some of them. The rows represent the claimants assessment of the project outcome – success or failure. The table shows the interpretation an XP proponent can confer upon each type of experience report so as to confirm their pre-existing belief in XP.

———–—————————————————-+—————————————-+

 Full XP   Subset of XP   -- --------- --------------

———–———————————————————————————————+

Success “XP has succeeded” “See how powerful XP is? Even a subset of the practices can yield success” ————- ——————– —————————————-

———–—————————————————-+—————————————-+

Failure “You weren’t doing xxx as well as you could have”, “You weren’t doing all the practices, “You weren’t committed enough”, so you weren’t really doing XP” “There’s something wrong with you” etc.
————- —————————————————- —————————————

———–—————————————————-+—————————————-+

The XPers have all their bases covered. No matter what the experience report, there is no need to ever cast doubt upon XP itself – there are always rival causes to be blamed.23 In this way, XP becomes nonfalsifiable.

Conclusion

There is an “essential tension”24 between being so skeptical of new technologies and methods that we miss the opportunity to exploit genuine innovations, and being so credulous that we are ourselves exploited by those willing to subjugate integrity to self-interest. Given the software industries’ history of fads, trends and passing enthusiasms, we would be wise to approach claims of innovation with caution – where those claims are accompanied by fanaticism and zeal, doubly so. As Thomas Henry Huxley warned:

Trust a witness in all matters in which neither his self-interest, his passions, his prejudices, nor the love of the marvelous is strongly concerned. When they are involved, require corroborative evidence in exact proportion to the contravention of probability by the thing testified.

There is no logical basis for dismissing out of hand every “next big thing” that comes along. But an awareness of confirmation bias, positive outcome bias and their contribution to the development of false beliefs should encourage us to seek evidence beyond that provided by popular media and effusive testimonial.

Thought Leaders and Thought Followers25

Fowler On “Appeals To Authority”

For a brief, shining moment there was hope. Through the exaggeration and braggadocio that so permeates the conversation of the Agile community, there came a fleeting glimpse of self-awareness – a flash of social perspective that could have precipitated a greater moderation and rationality in the methodological discourse. And then it was gone – swept aside by the force of yet another ill-considered generalization.

I’m referring to a recent blog entry by Martin Fowler entitled Appeal To Authority.26 In this entry, Fowler relates how he occasionally receives the comment “When a guru like you says something, lots of people will blindly do exactly what you say.” Fowler denies the existence of such an effect, and counters that what appear to be appeals to authority may really be just an artifact of lazy argument or sloppy self-expression.

The argument from authority is everywhere in the Agile and XP communities, and is a far more potent force than Fowler seems to appreciate. Here are just a few ways that the various so-called “thought leaders” and “spokesmen” employ direct and indirect appeals to authority.

  • Statements prefixed with “In my experience”, combined with the suggestion that this experience is extensive, are attempts to cast the speaker as a seasoned veteran whose word should be taken seriously. Having many years of experience only establishes that one is old, not that one is correct.
  • Sweeping statements and broad generalizations can make for powerful-sounding oratory, and suggest that the speaker possesses some kind of absolute knowledge i.e. that they are simply declaring information that they know to be factual. By abandoning the uncertainty and qualification, the speaker sacrifices accuracy for the sake of impact and elevates opinion to fact.
  • By inventing and promulgating cute slogans, folksy homilies and other media-friendly sound bites, speakers encourage others to quote them verbatim and dogmatically. Such quotation invests the statement, and thereby the speaker, with a faux authority.
  • With rare exception, the aforementioned comment from Fowler’s being one such case, the “thought-leaders” and “spokesmen” rarely acknowledge, let alone reject, their decoration with such grand titles. There is no attempt to discourage the use of such titles, beyond the occasional token self-deprecation.
  • Speakers claiming to represent the opinions and experiences of a group are naturally encouraging a view of themselves as leaders. Such speakers will not hesitate to claim “The Agile community believes X” or “The XP community does X”, even though the communities in question have not been consulted or surveyed, and in fact may have wildly varying and inconsistent views on the matter.

Fowler’s claim that appeals to authority are not a significant influence strikes me as disingenuous. Not only are such appeals frequent, they are at the very heart of the rhetoric. It should be kept firmly in mind that those most outspoken in this space are almost always consultants specializing in AM/XP.27 Consultants make their money by promoting themselves as authorities on some subject, so that others will hire them for their perceived expertise.

Ruin Your Career With Agility

An interesting blog entry, author unknown, came to my attention recently. Entitled How Agile Development Ruined My Career (Sort Of)28 it is the story of a Senior Director’s attempts to introduce Agile work practices into a company, and the consequences for himself. I have commented on the blog itself, and the XP fraternity has just begun to dissect it on =comp.software.extreme-programming=29 (posted 23 May 2004) which should make for entertaining reading.

  1. First published 29 Jul 2003 at http://www.hacknot.info/hacknot/action/showEntry?eid=11 ↩

  2. Inside Out, Alexandria Stein, North Star Press, 2002 ↩

  3. Seductive Poison, Deborah Layton, Anchor Books, 1999 ↩

  4. The Power of Cult Branding, M. Ragas and B. Bueno, Prima Publishing, 2002 ↩

  5. Software Development, July 2003 ↩

  6. Influence: The Psychology of Persuasion, Robert Cialdini, Quill, 1993 ↩

  7. Extreme Programming Refactored, M. Stephens and D. Rosenberg, Apress, 2003 ↩

  8. Enculturating Extreme Programmers, David M. West ↩

  9. First published 10 Nov 2003 at http://www.hacknot.info/hacknot/action/showEntry?eid=34 ↩

  10. http://c2.com/cgi/wiki?ToAyoungExtremist ↩

  11. Software Craftsmanship, Pete McBreen, Addison Wesley, 2002 ↩

  12. http://xp123.com/xplor/xp0006/index.shtml ↩

  13. First published 19 Apr 2004 at http://www.hacknot.info/hacknot/action/showEntry?eid=51 ↩

  14. Planning Extreme Programming, Kent Beck and Martin Fowler, p8 ↩

  15. Artima web logs forum, posted November 15, 2003, R. Martin ↩

  16. First published 16 Sep 2003 at http://www.hacknot.info/hacknot/action/showEntry?eid=22 ↩

  17. http://www.pairprogramming.com/ ↩

  18. http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF ↩

  19. http://www.typelogic.com/istj.html ↩

  20. First published 5 May 2004 at http://www.hacknot.info/hacknot/action/showEntry?eid=53 ↩

  21. Cited in Voodoo Science, Robert Park, Oxford, 2000 ↩

  22. The Skeptic’s Dictionary, Robert Carroll, Wiley, 2003 ↩

  23. http://c2.com/cgi/wiki?IfXpIsntWorkingYoureNotDoingXp ↩

  24. Why People Believe Weird Things, M. Shermer, Owl Books, 2002 ↩

  25. First published 24 May 2004 at http://www.hacknot.info/hacknot/action/showEntry?eid=55 ↩

  26. http://martinfowler.com/bliki/AppealToAuthority.html ↩

  27. Agile Methods / Extreme Programming ↩

  28. http://www.undefined.com/ia/archive/000158.html ↩

  29. http://groups.google.com/groups?group=comp.software.extreme-programming ↩