Patterns Design Essays - Software Design Pattern,

Patterns Design Periodically, someone asks for examples of successful (or non-successful) uses of 'fill-in-the-blank' software engineering technology. In truth, this is a difficult, if not impossible, request to fulfill. Why? There are several reasons: - Small examples, which are easily understood, can be (and often are) handily dismissed as toy (as opposed to real) applications. - It is difficult to justify the cost of a large (significant) test case (e.g., [Aron, 1969] and [Baker and Mills, 1973]). When fill-in-the-blank software engineering technology is used on a real project, accurate and detailed records are seldom kept. Thus, the results are often anecdotal. Even if accurate and detailed records are kept, it may be difficult to make any meaningful comparisons, since there may be few, if any, statistics for other similar projects which did not use fill-in-the-blank technology. - The results of a large-scale use of fill-in-the-blank technology are seldom, if ever, all positive, or all negative. This allows different interpretations for the same information. [One of the major problems is that success (i.e., what must be specifically shown to declare the technology viable) is seldom defined before the project begins.] The all-too-regrettable, and all-too-frequent, language/technology jihads (holy wars) often result from different interpretations of the same information. - The example is for a particular application domain, e.g., real-time embedded systems. Those with differing domains (e.g., MIS) can assert that the example is irrelevant for their domains. - In the case of a technology which may be implemented using a number of different programming languages, the number of problems increases dramatically, e.g.: - Some will observe that the example uses a programming language which they do not, cannot, or will not use. Thus making the example worthless -- as far as they are concerned. Bibliography none