SHARE

A Misnomer Taken to the ‘Extreme’

How much can be wrong with a name? Well, a whole lot, it turns out, when people are so put off by a poorly chosen name that they never find about a great new concept they could use to their advantage. Such is the case with one of the most significant advances in software quality […]

Written By

Jim Stewart

May 1, 2003

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

How much can be wrong with a name? Well, a whole lot, it turns out, when people are so put off by a poorly chosen name that they never find about a great new concept they could use to their advantage.

Such is the case with one of the most significant advances in software quality engineering in recent years. In the long term it may turn out to be as significant as structured programming, or as object-oriented programming, but unfortunately it earns nothing but rolled eyes and snide remarks when people first hear its ill-conceived name.

What I’m talking about, of course, is Extreme Programming, or “XP”. The name conjures up images of hackers blasting through code at a breakneck pace, using wild and crazy techniques to accomplish heretofore unknown programming feats.

Nothing could be further from the truth. The inventors of XP so named it because they took good development practices and carried them to their extreme, highest-quality potential. The practices they promote are aimed at reducing risk wherever possible. If anything, it should be called “Extremely Conservative Programming,” or XCP.

At ASIX, we are using XP, or, for the sake of this article, XCP, on a complex Java development project. Our team has gotten the XP religion, and is finding it can successfully deliver software on a predictable schedule that meets users’ expectations and at an exceptionally high level of quality. What is so extreme about that? To illustrate the problem, let’s take a quick look at some of the XP practices and let you judge for yourself if they are extreme or conservative.

1. Conservative Planning — Plan only for the next release. Identify your user’s most critical need and get that done first. Involve them in the plan so they own it and there are no surprises. Don’t make a move without their approval; don’t plan for future releases that you don’t yet understand. How can you be more conservative than that?

2. Conservative Scope Management — Build the smallest deliverable possible that gives a useful feature to your user. Put it in production immediately. Never take a chance that you will build something that is not the right thing or not useful to your users. Very conservative.

3. Conservative vision — Explain your design with a simple metaphor that everyone understands. Make sure everyone understands and accepts it before proceeding. If you can’t illustrate your business process in terms your users can easily understand there is something wrong; don’t bother starting. No risk there.

4. Conservative testing — Test everything, all the time. In fact, write the automated test before you even write any code. Always integration test, several times a day, after every task. If you can think of a way to test more conservatively, let me know.

5. Conservative coding — Programmers aren’t allowed to write any code without another programmer partner watching over their shoulder. Standards, documentation and design are constantly reviewed and walked-through in two-person teams as they are written. It is called “pair programming.” Talk about scrutiny, everyone has to be on their best behavior; no undocumented code or recreational Web surfing is likely to happen here.

6. Conservative customer communication — Keep your customer on site all the time. Never make an assumption without asking them what to do. It’s like never taking two steps out of the house without asking Mom for permission. No adventure here.

Wow, get the picture? This is about as far from your typical code-on-the-fly Web-script hacking as you can get. There is much more to the methodology, of course, with 12 core practices in total. Using any subset of them can provide benefits, but XCP fans say the true potential is not realized until all practices are used.

The objective of using XCP is to standardize on good practices and gradually improve the overall level of quality over time. Implementing a few of the XCP practices can be done by most IT organizations without difficulty, but effectively instituting all 12 requires some careful social engineering, and a level of commitment that is higher than some organizations are willing to make. For those who accept the challenge and implement it fully, XCP can change good but inconsistent solo developers into productive and highly professional teams.

It is a sad comment on the state of software engineering that something that promotes very high quality and development productivity is labeled “extreme”; it should be a basic expectation. From that perspective, the name “Extreme Programming” makes some sense as an attention-getter. It would be a pity, though, if the name unintentionally turns away those who need it the most.

XP was invented by a group of senior developers in search of a better way. They describe it as a lightweight methodology that addresses the needs of small teams of developers facing vague and changing requirements. In my experience that describes 95% of business system projects.

To find out more, check out the XP Web site, get the introductory book “Extreme Programming Explained” by Kent Beck and/or contact one of the growing number of local interest groups in XCP in larger cities.

Jim Stewart is the consulting practice director for ASIX, a vendor of software and IT consulting services based in Bellevue, Wash. He can be reached at jim.stewart@asix.com.