664 ON METHODOLOGY $19.2 Not all recipe-style approaches are doomed.If you sufficiently restrict the application domain until you are left with a basic set of problem patterns,then it may be possible to define a teachable step-by-step process;this has occurred in some areas of business data processing,where methodologists have identified a small number of widely applicable solution schemes.The eventual fate of such schemes,of course,is to be subsumed by software packages or reusable libraries.But as soon as you open up the problem domain,no simplistic approach will work;the designer must exert his best powers of invention.A method will help through general guidelines,through the example of previous successful designs-also the example of what does not work-but not much more. Keep these observations in mind both when reading part D and when going on to the methodology literature,where some methods make exaggerated claims.That is not necessarily a reason for rejecting them wholesale,as they may still include some useful advice;but they should be taken with a grain of salt. A point of terminology:it has become customary in some of the literature to talk about specific "methodologies",really meaning methods (actually even less:variants of a single general method,the object-oriented method).This practice may be viewed as just another mildly irritating example of verbal inflation-such as talking of repairmen as maintenance engineers-but is damaging since it leads readers to suspect that ifthe label is inflated the contents must be oversold.This book only uses the word methodology in the singular and sticks to the meanings that common dictionaries give for it:the study of methods;the "application of the principles of reasoning to scientific and philosophical inquiry";and a system of methods. 19.2 DEVISING GOOD RULES:ADVICE TO THE ADVISORS Before going into specific rules for using object-oriented techniques,it is necessary to ask ourselves what we should be looking for.The methodologist is entrusted with a serious responsibility:telling software developers how to write their software,and how not to write it.Ina field where religious metaphors come up so often,it is hard to avoid the comparison with preachers or directors of conscience.Such a position,as is well known,is subject to abuse;it is appropriate,then,to define a few rules on rules:advice for the advisors. The need for methodology guidelines The field of software development methodology is not new.Its origins may be traced to [Dijkstra 1968] Dijkstra's famous Go To Statement Considered Harmful letter and subsequent publications by the same author and his colleagues on structured programming.But not all subsequent methodological work has upheld their standards. It is relatively easy indeed to legislate about software construction,but the danger is great of producing rules that are useless,poorly thought out,or even harmful.The following guidelines,based on an analysis of the role of methodology in software,may help us avoid such pitfalls.664 ON METHODOLOGY §19.2 Not all recipe-style approaches are doomed. If you sufficiently restrict the application domain until you are left with a basic set of problem patterns, then it may be possible to define a teachable step-by-step process; this has occurred in some areas of business data processing, where methodologists have identified a small number of widely applicable solution schemes. The eventual fate of such schemes, of course, is to be subsumed by software packages or reusable libraries. But as soon as you open up the problem domain, no simplistic approach will work; the designer must exert his best powers of invention. A method will help through general guidelines, through the example of previous successful designs — also the example of what does not work — but not much more. Keep these observations in mind both when reading part D and when going on to the methodology literature, where some methods make exaggerated claims. That is not necessarily a reason for rejecting them wholesale, as they may still include some useful advice; but they should be taken with a grain of salt. A point of terminology: it has become customary in some of the literature to talk about specific “methodologies”, really meaning methods (actually even less: variants of a single general method, the object-oriented method). This practice may be viewed as just another mildly irritating example of verbal inflation — such as talking of repairmen as maintenance engineers — but is damaging since it leads readers to suspect that if the label is inflated the contents must be oversold. This book only uses the word methodology in the singular and sticks to the meanings that common dictionaries give for it: the study of methods; the “application of the principles of reasoning to scientific and philosophical inquiry”; and a system of methods. 19.2 DEVISING GOOD RULES: ADVICE TO THE ADVISORS Before going into specific rules for using object-oriented techniques, it is necessary to ask ourselves what we should be looking for. The methodologist is entrusted with a serious responsibility: telling software developers how to write their software, and how not to write it. In a field where religious metaphors come up so often, it is hard to avoid the comparison with preachers or directors of conscience. Such a position, as is well known, is subject to abuse; it is appropriate, then, to define a few rules on rules: advice for the advisors. The need for methodology guidelines The field of software development methodology is not new. Its origins may be traced to Dijkstra’s famous Go To Statement Considered Harmful letter and subsequent publications by the same author and his colleagues on structured programming. But not all subsequent methodological work has upheld their standards. It is relatively easy indeed to legislate about software construction, but the danger is great of producing rules that are useless, poorly thought out, or even harmful. The following guidelines, based on an analysis of the role of methodology in software, may help us avoid such pitfalls. [Dijkstra 1968]