A Baker's Dozen of Dirty Words

Systems development is a social act. Between consenting adult professionals, words are the primary tokens of interchange, and they serve as models of the ideas and energies we bring to our work. In my visits with so many people, in so many places, over so many years, about so many different issues and challenges, I have found a literal Babel of terms and phrases—words that muck up the conversation and make it tough to share understandings and agreements about what we have done and propose to do. I offer the following examples, with commentary and suggested alternatives:

Walkthrough When it first emerged in our vocabulary, this term seemed like a good idea: a way to present our work to peers in a way that allowed for critiques and spared the ego of the author. Over time, the practice deteriorated into muddlethroughs or stomp-throughs, and started to create more terror than enlightenment. It is a waste of time for an author stand up in front of a group of colleagues and walk them through the work. If the work is good, it will speak capably for itself. Instead, let the reviewers prepare in advance, and use the group time to communicate their comments to the author. Let the reviewers be responsible for the quality of the review process itself, and the author, in turn, be responsible for the quality of the work. My alternative: "review."

Quality Assurance Creating a person or group with the name "Quality Assurance" is admitting failure. The term implies that it is the dedicated job of someone else to assure quality, thus relieving the rest of us from concerning ourselves—and that there's a station near the end of the line where quality is somehow added to the product. Let's keep the acronym and change the word: I like "Quality Assessment."

Phase My battle cry for this millennium is: "Phase Out Phases!" The phases I have in mind are the linear string of development verbs arranged in a waterfall-style methodology. This approach guarantees failure by discouraging iteration, creating a perverse metrics history, blocking useful feedback from preliminary efforts, and forcing users into a one-time lump delivery of the finished system. We can do better by iteratively planning and accomplishing "event-based deliverables," organized around the external occurrences that require a system response.

OOA (Object-Oriented Analysis) I think this is a fraud. A generation ago, we might as well have talked about “subroutine-oriented analysis.” Objects offer an intriguing way to think about organizing the implementation of a system, and can be useful to designers and programmers. It’s perverse to suggest that business clients and users also embrace the Object perspective in order to review and certify models of the essence of their work. Years ago, before we had methods or knew any better, designers did requirements work; now, the OOA enthusiasts would have requirements modelers doing design work. I suspect that the notion of OOA stems from a need to make information modeling palatable to technologists. The core requirements of a system are the core requirements: let’s drop OOA and call it "essence modeling" instead.

Maintenance The semantic origins of this word are about "holding in the hand." This seems like a peculiar way to talk about post-delivery work on existing systems. Many shops administer this with an annual budget, renewable for each succeeding year if all the money has been spent. Generally, it turns out to be a compelling demonstration that Dr. Pavlov was right. If we lump all follow-up work under one category, we deny ourselves the opportunity to distinguish between new work initiated by clients and repair