While you’re downloading your patch for XP and installing it, you’ll need something informative. I give full kudos to Wired Magazine for including articles on software methodology such as the one from the current issue (the one with Jenna Elfman on the cover, I swear it’s her). The positioning is imaginative, like what would the world be like if we were all friends and everyone understood twice as much code as they understand now. It draws no hypotheticals on what an extreme programming “divorce” could be like, or how maybe we would start to see prime time dramas set in dev houses (after all, what is Law and Order except extreme lawyering?) But these thoughts are inevitable and fun, sooner or later you’ll be worm-proof and have to go back to your regular work, by yourself. Sniff.

Here’s what the article has to offer: The extent of the social and technical damage before “Extreme Programming” (XP in this context) was tried. How it works so well and who is using it. The shocking fact that “The practice adds 15 percent per programmer to the time it takes to complete a task.” (I would have thought more. If true it’s definitely worth it). The process of advocacy by Kent Beck, who says “If I had a charisma-ectomy in the beginning, XP would have gone nowhere.” (This is not a surface comment. Developers have their own charisma, so does code, and under no scenario does this come in to play more than in pair programming.) Finally I find out (where have I been) that my hero Steve McConnell not a fan. (Details I’m sure can be looked up on this, but I’ll guess them below and see where I’m wrong. Maybe.) Best of all, XP lets program managers off the hook by mandating that developers play “The Planning Game.” This is the process of building stories on cards instead of writing elaborate specifications. (I myself rely on screenshots at the outset. Then a powerpoint for the execs. After buy-off and concurrent with development, a spec for testers and doc writers. I guess I was doing it right.)

Gotta get these books mentioned in the article: Ellen Ullman “The Bug”, Watts Humphrey “A discipline for software engineering”, Kent Back “Extreme Programming Explained”

Gotta find the links for these guys if they exist: Weblog for Grady Booch of Rational Software, Yahoo group for XP programming, Kent Beck “computing rock star and provaceteur”, Tom Gilb “project management guru”

Here are the rules, with hyperlink to additional commentary

I.                    The Planning Game: Meet with coders, managers, and the customer each week to schedule tasks for the next phase. Update the plan regularly.

II.                 Small Releases: Put a simple system into production quickly, then release new versions on a short cycle.

III.               Metaphor: Create an analogy that expresses how the parts of the new system work.

IV.              Simple Design: Design simply, and remove complexity at every stage.

V.                 Testing : Write test programs that assure every portion of the code runs flawlessly before attempting a new task.

VI.              Refactoring: Edit the code to simplify, add flexibility, or remover redundancy.

VII.            Pair Programming: Write all code with two programmers on one machine.

VIII.         Collective Ownership: Permit anyone on the team to change code anywhere in the system at any time.

IX.              Continuous Integration: Bring components of the program together several times throughout each day to make sure they work in concert.

X.                 40-Hour Week: Strive to work no more than 40 hours a week. Never work overtime a second week in a row.

XI.              Onsite Customer: Include a real, live user on the team, available full-time to answer questions.

XII.            Coding Standards: Use agreed-upon styles and nomenclature to promote easy understanding of what the code does.

Hey, what gives, this isn’t the cute flashcards mentioned elsewhere! Weekly customer updates will result in weekly-sized dreams. I’m wary of this now.

Newsflash to UI designers: metaphors are out. Your product is not a console or a dashboard. But metaphors are still “in” for coders.

This rule does not take into account the fact that stress testing is not normal usage testing, neither of which can be fully automated.

Sometimes the more complex code for the compiler is easier to read and update for the programmer. The programmer wins.

Collective ownership can works as long as you have a great regression system and each person comments and initials their changes. Trouble is, comments have their own issues as per Steve McConnell. This should be proceeded with care.

Continuous integration sounds like a logistical nightmare. How about once a day.

The customer does not know how to design your product. And we don’t always know how to pick the right customer. One mistake in this can damage the product. This should also be proceeded with care.