Bad Advice by Any Other Name Is Still Bad Advice

Here s an extract of some advice from Kent Beck that we found on the C2 Wiki Web (check the referenced page for the full version):

When you sit zazen (the Zen mediation technique (I don t know how much you know about stuff like this, so I ll make little explanatory notes until you tell me to stop)), I am told that bizarre things can happen to you. You can get sudden bursts of psychic powers-precognition, far-seeing, telepathy, etc. Lots of people would think that was cool. They would hold onto these powers (if they could). Zen teaches exactly the opposite . . . .

. . . Because envisioning feels good. It brings many of the good feelings that really programming brings , but it can t crash. So people pursue visions instead of code (lots of design before you code), and visions of visions instead of code (lots of object oriented analysis), and the worst of all are those who pursue visions of visions of visions instead of code (the methodologists).

So ”congratulations on having gained the ability to envision objects before you program. Take a moment to enjoy the feeling when it comes. Then knock it the hell off. Find the one piece of the vision that seems most compelling and do the least possible amount of that. Then bless and release the vision and get back to listening ”to your code, your user , your partner, and yourself. ^[7]

Okay, don t get us wrong. We re not against Zen Buddhism. We think there are a lot of good ideas in Zen Buddhism. Way back when Doug was in college he used to read Zen literature while riding the New York City subways, clearing his mind and listening for the sound of one hand clapping. Now he listens for the sound of one man coding.

But there s just something wrong with couching a bunch of bad advice in catchy Zen-guru terminology. It s just wrong. Extreme Programming has about as much to do with Zen as Tammy Faye Baker has to do with religion. Is it Zenlike to write articles that proclaim you re the best team in the world ^[8] ? Is that what the Zen masters teach? Is it Zen-like to defend a mandated noisy programming environment that isn t conducive to quiet thought by saying concentration is the enemy ^[9] ? Is it Zen-like to pass off failed projects that refactor around in circles for 4 years as all being the responsibility of fear, the mind killer ^[10] ? And whether it s Zen-like or not, is it fair to clients to advertise an agile process when the clients don t realize that the price of agility is that they must free themselves from the concepts of doneness, and thereby schedules do not exist per se ^[11] ?

We believe that Kent Beck knows something about Zen. But we don t think that what he knows translates across to the legions of Extremo followers who dote on his every word. The archer who shoots true to the target without aiming is a nice poetic analogy, but as an excuse to avoid up-front design, it reeks. If we re managing a software project, give us a good design spec that can be reviewed by our senior engineers every time. And please , save us all from bad advice couched in catchy slogans.

VoXP
Voice of eXPerience: Packaged Dogma

by David Van Der Klauw

Let s hear from David one last time.

Thou Shalt Learn Speed Reading

As part of a task, my pair had to study some documentation found on the Internet. This had to be done in a pair, of course. As we read the document, I already understood some parts , but I had to wait while my partner slowly read and understood these sections. Similarly, at other points I was unfamiliar with the material and had trouble when my partner skipped ahead faster than I could take it in.

Later I complained to my manager, EI, that it was ridiculous to pair-read a document. EI said, Do you mean to tell me that it is not your fault for not learning to speed-read so that you can keep up with your partner?

I thought I had heard it all, but this XP zealot expected me to learn to speedread so that two people could read a Web page together.

My Karma Ran Over Your Dogma

XP can be described as 12 principles that must be followed closely. Some obvious questions arise:

Is it a good idea to replace common sense and judgment with close adherence to 12 principles?
If so, are the 12 XP principles the best possible 12 principles to follow?

To put the questions another way:

Should you follow a dogma?
Is XP the best dogma?

To answer the first question, Should you follow a dogma? : No. I believe that it s a great idea to try to follow several time- tested , basic principles as a guide, tempered by experience, judgment, and practicalities. Rigidly adhering to a dogma isn t the way to success in a complex and changing field such as software engineering.

To answer the second question, Is XP the best dogma? : I don t believe that XP is the best dogma available. Imagine you have a friend who is going off to run his own software company. He asks you to give him 12 principles to follow in order to be a success. Would you give him the 12 XP principles? I think not. I would suggest something like this:

Know your market.
Hire the best people available.
Motivate your people.
Keep the customer happy.
Manage risk.
Plan ahead, short term and long term .
Maintain balance. Don t overemphasize any one aspect of software development.
Use incremental development.
Use recent hardware and technology, but avoid the latest.
Keep studying and learning.
Learn from your mistakes.
Make rules but trust the judgment of your people to break the rules when needed.

I spent just 10 minutes thinking of these rules. Even so, I m sure that they re a better guide to success than the XP principles.

Imagine there was a competition where developers submitted their best 12 principles for software development. All entries were given a score by an expert panel of judges. How well would XP score?

My feeling is that XP wouldn t score highly at all when compared to other available principles.

The point I m trying to make is that XP shouldn t be selected just because one or more of its principles have some merit. That isn t good enough. XP should only be selected if you decide to follow a 12-principle dogma, and if those 12 XP principles are the best 12 available.

My impression of XP is that it s a way of allowing software to be written by people who aren t really good enough to be writing software. By following these simple rules, novices can avoid disaster and get the job finished.

For novices, a 12-principle dogma like XP might be just what is needed to get them over the line. However, for experienced professional developers, I believe that a dogma and a one- size -fits-all philosophy is a major mistake.

Extremes Are Stupid

I believe that a major flaw in XP is that it takes things to an extreme. I believe in doing things in moderation and trying to optimize the value by trading off one factor against another. In life, I find that rarely is the optimum achieved at some extreme point.

From the preface of Extreme Programming Explained :

XP takes commonsense principles and practices to extreme levels.

. . . If code reviews are good, we ll review code all the time (pair programming)

. . . If testing is good, everybody will test all the time

. . . If design is good, we ll make it part of everybody s daily business

. . . If simplicity is good

. . . If architecture is important, everybody will work defining and refining the architecture all of the time

I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10. ^[12]

Hello! Does anybody have a sound system at home? Can you tell me how good it sounds when you turn all the knobs to their maximum?

. . . If it s good to eat at lunchtime, then let s eat all of the time.

. . . If pay rises are good, then let s have a pay rise every month.

. . . If cleaning toilets is important, then we ll make it part of everybody s daily business.

Extreme Simplicity

There s a lot of sense in doing things simply. Einstein said, We should make all things as simple as possible, but no simpler. However, let s use the example of taking simplicity to an extreme in order to show how taking something to an extreme narrows its range of applicability.

Here goes: Many software developers make things more complex than necessary. If I advise that developers should write slightly simpler code, then I d probably be right in 99% of cases. Further, if I advise that developers should write moderately simpler code, then I d probably still be right in 90% of cases. However, if I advise that developers should always write code that is extremely simple, then my advice would only be correct in very few cases.

The more extreme I become, the more I narrow the fit of my advice. It s a matter of statistics and bell curves and all that.

If the Shoe Doesn t Fit . . .

The result of combining several practices to extreme levels is that XP will only fit very rare situations.

The white book says, XP is a lightweight methodology for small-to-medium sized teams developing software in the face of vague or rapidly changing requirements. ^[13] That s a very narrow focus. This is precisely the point I m making. Extreme practices make for an extremely limited range of suitability. And I m not convinced that much of the work done by the CompanyXYZ product development team fits within this narrow range. Last time I looked , CompanyXYZ was a large team programming for well-known, largely unchanging requirements. Why are we doing XP?

SATIRE WARNING
Neutralizing the Reality Distortion Field

Dooo doooooo doo doo doo doo doo . . .

Spock: Captain, our situation is quite precarious. All of our sensors are out, and our shields are down. We are quite vulnerable to attack, sir. I suggest we head for the nearest star base.

Kirk: That s . . . all right, Mr. Spock. Just sit in the lotus position and meditate. When the Klingon ships appear, we will know. Our photon torpedoes will fly straight to their . . . targets without aiming.

Spock: Highly illogical, Captain. My calculations indicate that our odds of survival would be 3872.6 times better if the targeting computer was working. I respectfully suggest that you allow me to initiate repairs , Captain.

Kirk: Permission denied , Mr. Spock. We must believe in the power of extreme guidance.

Spock: I ve got some star charts here, Captain. There s a reality distortion field up ahead, and we wouldn t want to run into it.

Kirk: Documentation, Mr. Spock? I m . . . disappointed in . . . you. You know all documentation is dated and obsolete. Meditation, that s the key. Meditation, not documentation.

^[7] See http://c2.com/cgi-bin/wiki?ExtremeProgrammingMaster.

^[8] Kent Beck posting to the C2 Wiki page To Ayoung Extremist, http://c2.com/cgi-bin/wiki?ToAyoungExtremist .

^[9] Chet Hendrickson, DaimlerChrysler: The Best Team in the World, http://www.computer.org/SEweb/Dynabook/DaimlerChryslerSdb.htm (reprinted from Computer , Vol. 32, No. 10, October 1999).

^[10] Ron Jeffries, posting to the C2 Wiki page Pair Programming Ergonomics, http://c2.com/cgi-bin/wiki?PairProgrammingErgonomics.

^[11] Chet Hendrickson, When is it not XP? , http://www. xprogramming .com/xpmag/NotXP.htm, December 5, 2002.

^[12] Robert C. Martin posting to OTUG ( http://www.rational.com), subject: Estimates and Promises, October 13, 2000.

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