Extremist Programming

A conversation with a co-worker recently reminded me of a time when our manager lamented the fact that test-driven development, a practice in Extreme Programming (XP), was being touted by a "mainstream" Java periodical. His comment was that if the mainstream commentators were talking about it, then it wasn't so "extreme" after all.

Since that came up, I thought I'd share my recommendations for those who want to keep the "extreme" in "extreme programming." The following was emailed to my (somewhat perplexed) teammates after our manager's comments.

Apparently Extreme Programming is no longer extreme enough. If an organization truly wants to represent extreme coding practices, it is time to shift to "Extremist Programming."

The following explanation outlines some of the key differences between Extreme Programming and Extremist Programming. (With apologies to Kent Beck. ...and, also, to anyone with even the slightest sense of decency.)

Comparison: Extreme Programming vs. Extremist Programming

Planning:
Extreme Programming - User stories are written.
Extremist Programming - User stories are written in blood.

Extreme Programming - Make frequent small releases.
Extremist Programming - Make a new release each time a line of code is written. (For Java: Typing a semi-colon launches a new build.)

Extreme Programming - Move people around. (No part of the code is known by only one developer.)
Extremist Programming - All developers shall memorize every line of code with recitations on demand.

Extreme Programming - Stand-up meetings.
Extremist Programming - STAND UP! All chairs shall be removed from the office immediately.

Designing:
Extreme Programming - Create spike solutions with which to explore possible resolutions to design issues.
Extremist Programming - Build spikes upon which to impale developers who cannot resolve design issues immediately.

Extreme Programming - No "future functionality" is added.
Extremist Programming - No future functionality is needed. "Version One" shall be the ultimate and final version of the product; no user will ever request additional features (and live).

Coding:
Extreme Programming - The customer is always available.
Extremist Programming - The customer is held in a small closet in the corner of the office to ensure immediate responsiveness.

Extreme Programming - Development of all code is test-driven.
Extremist Programming - Development of all code is intimidation-driven.

Extreme Programming - All production code is pair programmed.
Extremist Programming - Developers shall be surgically joined together for the duration of the project.

Extreme Programming - No overtime.
Extremist Programming - No one leaves.

Testing:
Extreme Programming - All code must have and pass unit tests.
Extremist Programming - All code failures result in the pummeling of the developers until transfusions are medically necessary; hence the new name "Unit (of blood) Testing."

Extreme Programming - When a bug is found, tests are created.
Extremist Programming - When a bug is found, scapegoats are designated and witnesses are eliminated.