Fear


Fear. This emotive word is often used by XPers (both the authors and the practitioners ). They use the word to define the XP development process and to justify why other people seem to prefer different approaches to software development.

A courageous and all-encompassing claim made in the Fear chapter in Planning Extreme Programming is this:

GROUCHO  

Unacknowledged Fear Is the Source of All Software Project Failures

This is one of those catchall statements that people seem to love so much, but that tend to be false because they have oversimplified beyond reason. There s a very common desire to make claim to having the answer. It gives one a unique buzz, that Eureka! feeling.

The love of money is the root of all evil. That ll explain serial killers just fine then. People love to simplify the world, or try to. It makes them feel safe and sound wise.

A nice payoff. And if something doesn t fit their homespun wisdom, they ll just play games with the dictionary, shoehorning one word into another until it does.

Fear = Doubt = Unknown = Dark = Bed- wetting

Or, to quote Chet Hendrickson reciting a C3 war story,

GROUCHO  

This lack of knowledge caused us to become afraid . . . and as we know, ˜Fear leads to anger. Anger leads to Hate. Hate leads to suffering. [16]

Nevertheless, it s an interesting hypothesis, that every software project that has ever failed comes down to one thing: fear. Is fear, then, a fundamental universal source? Is it right up there with light, astrology, and life itself as a binding element that governs us all, and from which nobody can escape? Or does it apply merely to software projects?

Fear and the Extremo Culture

The aura of fear has grown up around Extremo culture, so that many people who disagree with XP s teachings are simply afraid to speak out. Those who do often do so apologetically for fear of the possible repercussions . For example, Application Development Advisor magazine ran a short article that criticized XP. Its introduction ran as follows :

This month, AngryYoungManGary Barnett is stepping on the toes of some dangerous people ”the devotees of the eXtreme Programming cult. Incoming . . . [17]

Their concern was not entirely unfounded. Following its publication, the article The Case Against Extreme Programming was publicly flamed by pro-XPers but privately lauded by developers who wished to be kept anonymous. A couple of developers, who were working on different XP projects at the time, were afraid of damaging their career prospects should their employers or coworkers discover that they were anti-XP subversives.

We ve never before heard of a software methodology that promotes this level of fear and distrust . This is hardly a healthy situation.

Fear and the Extremos

Chet Hendrickson (an XP coauthor who was also involved in the C3 project) wrote an article on XProgramming.com that included a section titled Fear Is the Mind Killer.

start example

We quote from Fear Is the Mind Killer back in the section Doin the Simplest Thing That Can Possibly Work in Chapter 2.

end example
 

The f word is, of course, used liberally in XP because it s the antithesis of courage, which is one of the four XP values. For many, however, the usage comes across as an openly contemptuous goading of people who don t agree with the XP practices. If you don t like XP, it must be because you re afraid of what it offers.

Remember being called scaredy-cat back in elementary school? (Or was that just us?) It isn t really that different. It s pure emotional rhetoric, not entirely appropriate for defining a software development process.

Not long after Matt uploaded the first version of The Case Against Extreme Programming article onto his Web site, Ron Jeffries (in a rebuttal placed on the Agile Modeling mailing list [18] ) suggested that the author fears change and wants to suppress it. Then he added, He s afraid of integration. Why fears ? Why not is wary of change, prefers a changeless approach, approaches change with caution ?

It wouldn t be nearly as emotive. When discussing criticism of XP, XPers frequently shoot the messenger. Take a look at some of the discussions on comp.software.extreme-programming to see what we mean.

In Planning Extreme Programming , the very existence of a software process is justified in terms of fear of the customers and developers:

GROUCHO  

Why do we need a software process? For the same reason that we need laws, governments , and taxes: fear. [19]

The theory is that in order to develop effectively, you must acknowledge your fear of what may go wrong. The chapter goes on to give a bill of rights for customers and developers, where each right is intended to resolve the individual s respective fears. We could argue that, technically speaking at least, these are privileges, not rights ”unless the rights are all bound in an ironclad contract (which is contrary to XP anyway; see Chapter 11).

From the same chapter in Planning Extreme Programming :

GROUCHO  

We huddle in fear behind fortress walls, building them ever stronger, adding ever more weight to the development processes we have adopted. We continually add cannonades and battlements, documents and reviews, procedures and sign-offs, moats with crocodiles, torture chambers, and huge pots of boiling oil. But when our fears are acknowledged and our rights are accepted, then we can be courageous. [20]

This suggests that normal contingency and risk-reduction practices such as documentation, reviews, procedures, and sign-offs are simply things we do to prevent ourselves from being scared. Contingency in this sense is a security blanket that we clutch tightly to ourselves in a desperate effort to prevent the big bad monster from emerging from beneath the bed, as it does each night, to do scary things like make our projects late. Damn those monsters.

Put another way, these practices are simply there to CYA [21] ”so that when your manager or customer (who are both equally scared, by the way) asks for reassurance that his security blanket is in place, you can demonstrate (with a slightly shaky voice) that it is. The monsters are locked out . . . for now.

On OTUG, Robert C. Martin suggested that what most of us regard as reasonable procedure ”writing down specifications ”is regarded as CYA by everyone, not just XP proponents. The following response was given by Doug (in a sort of Wiki parody):

Really? I guess I must be nobody then, because I regard WritingRequirementsDown to be fundamentally important to DeliveringSoftwareOnSchedule.

On the other hand, I regard NeverWriteAnythingDown as fundamentally important to the philosophy of TheyCan tClaimI mResponsible. And the repeated declarations that the cancellation of the C3 project had NothingToDoWithUs is one of the most classic cases of TheyCan tClaimI mResponsible that I ve ever seen.

WritingRequirementsDown is also fundamentally important when it comes to DoingAGoodDesignBeforeCode, and allows for WritingDesignSpecsDown, which is really useful for making ReviewableDesignsBeforeCodingStarts. This, in turn , leads to RemovingDefectsBeforeCode, and GoodCleanArchitecture, (that is, GettingTheOriginalFactoringPrettyCloseBeforeCode) which means you can spend LessTimeRefactoringAndRerunningTests which, of course explains why it s all helpful in DeliveringSoftwareOnSchedule. [22]

start sidebar
SATIRE WARNING
It All Depends on the Fear

Our pink slips are here! Loretta shouted excitedly, bursting into the room.

That s not really a good thing, JoJo pointed out, from where he sat sprawled in front of his PC, idly clicking through advocacy threads on Google Groups. He couldn t do any real work because, until Loretta burst in, he had been the only person in the room.

Actually, they re not here as such, retracted Loretta. I just overheard a comment from one of the ˜rumor radiators downstairs.

So the project s a failure, then? JoJo murmured disconsolately. It s being cancelled?

We don t know that, Loretta replied, pulling up a chair . Not for sure. Not yet. It all depends on the Fear .

The what? choked JoJo. You know, the Fear. Every project that fails, fails because of fear, Loretta replied. But our project died because we blew the entire budget on snack food, team bonding events, and endless refactoring! exclaimed JoJo.

Aha, no, Loretta countered, the management was afraid to give us more money.

Well . . . JoJo responded. He was torn between the natural urge to argue and the instilled value of respecting Loretta s opinion. But surely, the project was simply failing to deliver what it had promised ! he blurted finally.

Aha, Loretta replied sagely, the management was afraid of being seen as failures and not the devil -may-care OO pioneers that we turned out to be.

end sidebar
 

Was Fear the Cause of C3 s Failure?

At the start of this section, we discussed Kent Beck s statement that unacknowledged fear is the source of all software project failures. To investigate this, let s take a case study of a known failed software project. Off the top of our heads . . . C3? Let s examine whether C3 s failure could be attributed to unacknowledged fear.

There are, of course, several different versions of why C3 failed (or didn t fail, depending on the version in question). Let s examine each of these in turn, [23] in the context of XP s fear antivalue :

  • It was cancelled inexplicably. This explanation leaves the door of speculation wide open to all sorts of fearsome monsters. My favorite theory is that some form of morbid spiritual force, or dark angel, drifted into the C3 pair-programming room, looked around, then made a beeline for the higher management at Chrysler and inflicted terrible fear into their minds, causing them to cancel the project immediately. We can t escape this force that is known as fear . It s inexplicable. Of course, we re just hypothesizing here.

  • The goal donor (the on-site customer) and the gold owner (the real customer) didn t agree. This explanation is a bit more concrete. There was a gradual shift in emphasis of the project over its many years of meandering and refactoring. When the XP coach left the project, the goal donor and gold owner began to talk to each other less and less, so that eventually there was a whopping disparity between what the goal donor was creating and what the gold owner was prepared to hand over yet another purse of gold for. Perhaps they weren t talking because they were afraid of each other? Or was the goal donor afraid of what the gold owner would think if she knew what the team was up to?

  • The management had forgotten about the project and suddenly remembered to cancel it. Oops. Last one out switch off the lights. Better yet, leave the lights on. The darkness is a bit scary.

  • When the project missed its Y2K deadline and the mainframes didn t die anyway, it got cancelled. Definitely not a failure, though. Perhaps the fear thing here was to do with management s fear of how much more money would be wasted if they continued to plough hard cash and resources into a project that was already massively behind schedule and over budget.

  • None of this really matters because it was just a research project anyway. Um, ya. Not really anything to do with fear, though.

  • We stopped providing value to the customer. To quote Chet Hendrickson:

    With all that being said, what really happened at C3? I don t think that there is one simple answer to that question. The best answer is that we stopped providing value to our customer. Elsewhere on this page the bifurcation of our customer is discussed. The fact that we had two customers, with differing goals, means that we violated the principle of a single on-site customer. Let this be a lesson to you! Your customer must speak with one voice and if that is not the case you will suffer. [24]

This seems like a plausible explanation ”the customer got bifurcated ”but was it due to unacknowledged fear? Doesn t seem like it.

start example

We discuss customer bifurcation in more detail in Chapter 5.

end example
 
  • Early cancellation isn t really failure ”in fact, termination can be success. [25] Because the schedule doesn t exist per se, and a software project is never done. Well, if the project didn t really fail, then fear can t have been a factor, right?

start sidebar
Is XP Itself Driven by Fear?

All methodologies are based on fear. You try to set up habits that prevent your fears from becoming reality. XP is no different in this respect from any other methodology. . . . [26]

In Extreme Programming Explained, Kent Beck describes the fears that drove his design of XP (fears such as Doing work that doesn t matter and Making business decisions badly ).

In addition to these, we ve discovered that XP as a software development process is driven by fear at a number of different levels. The fears we ve identified so far include the following:

  • Fear of up-front design

  • Fear of detailed written requirements

  • Fear of documentation

  • Fear of accountability

  • Fear of coding alone

end sidebar
 

If You re Not Doing XP, Then You Must Be Afraid

Was VCAPS (another XP project from around the same time as C3) the victim of unacknowledged fear? The project was cancelled because it was replaced by another system, already under development in the same organization, that rendered VCAPS obsolete before it was finished.

Speaking as outside observers, we feel that VCAPS would have benefited from some more stringent up-front analysis work. This would have helped to establish whether or not the project was safe from cancellation due to external factors.

start example

We discuss the type of analysis work that would have benefited both VCAPS and C3 in the section Programming Without a Safety Net in Chapter 8.

end example
 

So it seems more likely that unacknowledged fear was not, strictly speaking,the root cause of VCAPS s failure. It was, instead, a much more insidious beast : unrealized fear. The lack of fear. Bold, earnest, enthusiastic, na ve, youthful courage.

As for C3, the root cause was similar. The team members were so busy looking-inward on their project, refactoring to their heart s content, and making the code technically pristine that they forgot to look out. They forgot to think the unthinkable, to be afraid of what might happen if they don t bolster their process with some suitable layers of contingency.

start example

We give some examples of contingency in the section How to Be Agile Without Being Fragile in Chapter 15.

end example
 

So generally , the XP discussion of fear as the antivalue of courage isn t without merit. It s what you do with the fear that counts. In Planning Extreme Programming , the implication is clear: Be totally driven by fear and you will end up putting too many safety nets in place. There is a trade-off, a balancing act between the gravity of the project (i.e., how hard it will fall, how much money will be wasted, whether real lives will be put at risk should something go wrong) and the amount of process overhead that is put in place to protect against things that might go wrong.

Still, though, this is not really being afraid. Fear suggests scary monsters (to us, at least). Cautious, yes. Heavy on the forethought, prudent, sangfroidally challenged. But afraid? Mmm, not really. Would you say that you are afraid of a software project?

This is where XP becomes a potential catalyst for a big cultural split in the software engineering world. Some people just don t like the pejorative terminology that overflows from XP. Other people love it or at least see nothing wrong with it. Possibly, this is why XP is so often the subject of heated debates. It s a subtle cause, but it s just possible that XP is rubbing some people the wrong way, and the people that are being rubbed are in turn rubbing the XPers in return, without really understanding why. In turn, XPers suggest that if you re not doing XP, then you must be afraid.

[16] Ron Jeffries, Ann Anderson, and Chet Hendrickson, Extreme Programming Installed (New York, NY: Addison-Wesley, 2000), p. 197.

[17] Gary Barnett, XP “ it s about ˜How , not ˜Tao , http://www.appdevadvisor.co.uk/Downloads/ada6_2/AngryMan6_2.pdf, March 2002.

[18] See http://www.topica.com/lists/agilemodeling.

[19] Kent Beck and Martin Fowler, Planning Extreme Programming (New York, NY: Addison-Wesley, 2000), p. 7 (from Chapter 2, Fear ).

[20] Ibid., p. 9.

[21] Cover your a**.

[22] Doug Rosenberg posting to OTUG ( http://www.rational.com), subject: CYA, October 11, 2000.

[23] Each version of C3 s untimely demise can be found on the Web (e.g., on the C2 Wiki); most of these are also described in Chapter 2. We re leaving it as an exercise for the reader to hunt them down ”sort of an Easter egg hunt for the morbidly curious .

[24] See http://c2.com/cgi/wiki?CthreeProjectTerminated .

[25] See http://www.c2.com/cgi/wiki?TerminationCanBeSuccess and the linked pages nearby.

[26] Kent Beck, Extreme Programming Explained: Embrace Change (New York, NY: Addison-Wesley, 2000), p. 165.




Extreme Programming Refactored
Extreme Programming Refactored: The Case Against XP
ISBN: 1590590961
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net