(I am finally publishing some old drafts. I started this entry way back in January)

I remember Brian Marick once mentioning on the Agile Testing mailing list that 'plan' is a ruined word. Elizabeth Hendrickson offered 'requirement' as a similar word that has also lost its meaning.

The sad fact is, that the world of IT is littered with the debris of buzzword fetishism with the result that almost every imaginable word is loaded with several (often incompatible) meanings.

Take the following example: Extreme Programming includes two types of testing as an intrinsic part of the methodology definition (one is of course free to do other types of testing, these are simply explicitly part of the metholodgy): One is the testing done as part of Test Driven Development (often called 'unit testing') the other has had (at least) these names:

• Functional Tests
• Acceptance Tests
• Customer Tests
• Story Tests
• Coded Functional Tests (this was the term on a big ThoughtWorks project)
• Build Verification Tests (this was also used on a big ThoughtWorks project)

The problem is -- all of these terms carry baggage from other schools of testing that are very different from what XP'rs actually use these tests for. So what do we do? Unfortunately, all of the typical solutions fall short:

• Create a new name -- that's what gave us the above problem.
• Prepend XP -- XP functional tests, XP-style Acceptance Tests, etc.
• Explain it every time -- "Those tests that we run after we run our TDD tests, that tend to test end-to-end functionality and are tied to our stories. We like them to be writtten (or at least specified by the customer) and automated so they can be run with each build."
• Predefine Terms for the project -- "When I say Story Tests, I mean "Those tests that we run after..."
• Gesture and Grunt

In practice we use them all (even the gesturing and grunting). But the trend does seem to be of epidemic proportions in IT (meaning dilution, not grunting). Here are some more overloaded, ambiguous terms that mean wildly differenent things to different people:

• Architecture
• Design
• Release
• Build
• Iteration
• Refactor
• Bug
• Portal
• Server
• Application
• (an endless list of acronyms and silly code names)

With all of this babel, its a wonder we get anything done at all! And yet to some extent its an unavoidable side-effect of human communication. In fact, there are entire areas of Philosophy and Linguistics that discuss the limitations of language. Perhaps IT needs a bit of 'Wittgensteinian therapy'.

Or maybe its time to simply reset the IT lexicon. Let's just delete the computing dictionary, and start over. Hopeless you say? Perhaps, but I do think the solution points in the right direction.

Perhaps, the first (and even the only) requirement for gelling a productive software development effort is to build a shared context of definitions -- and leaving our own preconceived notions at the door. By acknowledging that we can't skip this step, that every new encounter will result in the need for this swapping of context (this is also a strong argument for keeping gelled teams together) we can reset our own IT lexicon and thus be ready to build a new one for each project.

So, after thinking this through, I don't know that I agree with Brian. 'Plan' is only a ruined word in the sense that we can't assume that people share our understanding of the term. But maybe what Brian has pointed out is that we shouldn't assume that we share any context with anyone -- unless we've first taken the time to build one. For if words can be forever ruined, it going to get to the point Real Soon Now in IT... where... we.... can't..... say....... any......... thing........... at...