10 True Believer

Nearly all of the popular methods in software engineering arose from practitioners’ experience, not from basic research. People were motivated to write down what worked for them on their projects, and the experience got transferred from a small group to many others. By communicating with many of the leading process designers, we know that most of them concede that (1) their methods were developed for certain domains or project sizes and (2) their methods have never been expected to work exactly as described for all possible environments.

Our CASE tool ProMod, in its early versions, flagged as errors a lot of things that our customers considered okay. Whatever methods we implemented, we did them by the book—we were true believers. Whenever the text suggested something or showed an example, we abstracted from that and coded it into hard rules. We flagged it as an error when a user did not exactly follow our rules. Only over time did we learn to flag things as warnings instead of errors. Even more, we learned that we had to make all of the messages optional; in other words, we let the user decide whether to turn them on or off, and we allowed the rules to be violated. —PH

Although most process books contain fair warnings about the applicability of the methods, true believers either ignore these warnings or never make it to the pages that contain them, which are usually found toward the end. Currently, it is very much the vogue to be an XP advocate, even among people who have never read the penultimate chapter of Kent Beck’s first book, in which he clearly explains the limits of the approach.

One of my clients is considered by her boss to be a major success factor because of her software engineering skills and enthusiasm. We discussed UML activity diagrams in their latest variety, Version 2.1. I was surprised to hear that she refused to use the UML tool chosen by the company “since it did not support all the new features such as n-dimensional swim lanes, interruptible regions, and parameter sets.” Instead, she preferred to use Visio shapes, which gave her the freedom to follow all the suggestions of the new action language. She claimed she really needed them all. She was a true believer. —PH

True believers on your project can bog the work down. Instead of concentrating on the content, they fight methods wars. Often, true believers are found among consultants brought on board to help with methods. The ultimate clash is achieved when two principals (either insiders or consultants) turn out to be true believers of two different methodologies. Bring on the proxy wars! No matter how good they are, you’d be better off without either of them so you can get on with your business.

“Different methodologies are needed on different projects.”—Alistair Cockburn[1]

  1. Cockburn, A., Agile Software Development (Reading, Mass.:Addison-Wesley, 2002).