On methodology ntirely devoted to methodology,the next few chapersmaking up part Dofthis book-examine how to address the issues facing object-oriented projects:how to find the classes;how not to misuse inheritance;the place of object-oriented analysis; fundamental design ideas ("patterns");how to teach the method;the new software lifecycle.The result will,I hope,help you understand how best to take advantage of the techniques that we have now finished exploring. It is appropriate,before going into the study of the rules,to reflect on the role of methodology in software.This will be an opportunity to define meta-rules-rules on how to make rules-which will help us devise sound methodological advice and separate the best from the rest in the methodological literature.In passing we will devise a taxonomy ofrules,finding out that certain kinds are more desirable than others.Finally we will reflect on the attractive and dangerous role of metaphors,and take a short lesson in modesty. 19.1 SOFTWARE METHODOLOGY:WHY AND WHAT People want guidance.The quest for Principles of Truth,which one only has to follow to succeed,is neither new nor specific to software. The software literature,including for the past few years its object-oriented branch, has capitalized on this eagemess and attempted to offer recipes.This has resulted in much useful advice being made available(along with some more questionable ideas). We must remember,however,that there is no easy path to quality software.Earlier chapters have pointed out several times that software construction is a challenging task.In the past few years our grasp of the issues has vastly improved,as illustrated in particular by the techniques presented in this book,but at the same time the size and ambition of what we are try ing to do has been growing even faster,so the problem remains as difficult as it ever was It is important,then,to know the benefits and limitations of software methodology. From the following chapters and from the rest of the object-oriented literature,you are entitled to expect good advice,and the benefit of other people's experience.But neither here nor there will you find a sure-fire way to produce good software. A comparison made in an earlier chapter helps set the limits of what you can expect. In many respect,building a software system is similar to developing a mathematical theory. Mathematics,as software construction,can be taught,including the general principles that help talented students produce brilliant results;but no teaching can guarantee success
19 On methodology Entirely devoted to methodology, the next few chapters — making up part D of this book — examine how to address the issues facing object-oriented projects: how to find the classes; how not to misuse inheritance; the place of object-oriented analysis; fundamental design ideas (“patterns”); how to teach the method; the new software lifecycle. The result will, I hope, help you understand how best to take advantage of the techniques that we have now finished exploring. It is appropriate, before going into the study of the rules, to reflect on the role of methodology in software. This will be an opportunity to define meta-rules — rules on how to make rules — which will help us devise sound methodological advice and separate the best from the rest in the methodological literature. In passing we will devise a taxonomy of rules, finding out that certain kinds are more desirable than others. Finally we will reflect on the attractive and dangerous role of metaphors, and take a short lesson in modesty. 19.1 SOFTWARE METHODOLOGY: WHY AND WHAT People want guidance. The quest for Principles of Truth, which one only has to follow to succeed, is neither new nor specific to software. The software literature, including for the past few years its object-oriented branch, has capitalized on this eagerness and attempted to offer recipes. This has resulted in much useful advice being made available (along with some more questionable ideas). We must remember, however, that there is no easy path to quality software. Earlier chapters have pointed out several times that software construction is a challenging task. In the past few years our grasp of the issues has vastly improved, as illustrated in particular by the techniques presented in this book, but at the same time the size and ambition of what we are trying to do has been growing even faster, so the problem remains as difficult as it ever was. It is important, then, to know the benefits and limitations of software methodology. From the following chapters and from the rest of the object-oriented literature, you are entitled to expect good advice, and the benefit of other people’s experience. But neither here nor there will you find a sure-fire way to produce good software. A comparison made in an earlier chapter helps set the limits of what you can expect. In many respect, building a software system is similar to developing a mathematical theory. Mathematics, as software construction, can be taught, including the general principles that help talented students produce brilliant results; but no teaching can guarantee success
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]
$19.2 DEVISING GOOD RULES:ADVICE TO THE ADVISORS 665 Theory The first duty of an advisor is to base his advice on a consistent view of the target area: Theoretical Basis methodology principle Software methodology rules must be based on a theory of the underlying subject. Dijkstra's example is still a good guide here.He did not just attack the Goto instruction for reasons of taste or opinion,but supported his suggested ban by a carefully woven chain of reasoning.One may disagree with some of that argument,but not deny that the conclusion is backed by a well thought-out view of the software development process.To counter Dijkstra's view you must find a flaw in his theory and provide your own replacement for that theory. Practice The theory is the deductive part of software methodology.But rules that would only be rooted in theory could be dangerous.The empirical component is just as important: Practical Basis methodology principle Software methodology rules should backed by extensive practical experience. Perhaps one day someone will disprove this principle by devising a brilliant and applicable method of software construction through the sole power of abstract reasoning. In physics,after all,some of the most directly practical advances originated with theoreticians who never came close an experiment.But in software engineering the case has not occurred-all the great methodologists have also been programmers and project leaders on large developments-and seems unlikely to occur.Object technology in particular is among other things,an intellectual tool to build large and complex systems; the only approach,in fact,that has attempted consistently and comprehensively to reach this goal.One can master the essential concepts through taking classes,reading the literature,performing small-scale experiments and thinking further,but that is not preparation enough to give good methodological advice.The experience of playing a key role in the building of large systems-thousands of classes,hundreds of thousands of lines-is indispensable. Such an experience must include all activities of the software lifecycle:analysis design,implementation,and of course maintenance (the final reckoning,at which one recognizes whether the solution adopted at earlier stages stands the test of time and change,or collapses miserably). Analysis experience,or even analysis and design experience,is not enough.More than once I have seen analysis consultants who do their job,charge their fees,and leave the company with no more than "bubbles and arrows"-an analysis document.The
§19.2 DEVISING GOOD RULES: ADVICE TO THE ADVISORS 665 Theory The first duty of an advisor is to base his advice on a consistent view of the target area: Dijkstra’s example is still a good guide here. He did not just attack the Goto instruction for reasons of taste or opinion, but supported his suggested ban by a carefully woven chain of reasoning. One may disagree with some of that argument, but not deny that the conclusion is backed by a well thought-out view of the software development process. To counter Dijkstra’s view you must find a flaw in his theory and provide your own replacement for that theory. Practice The theory is the deductive part of software methodology. But rules that would only be rooted in theory could be dangerous. The empirical component is just as important: Perhaps one day someone will disprove this principle by devising a brilliant and applicable method of software construction through the sole power of abstract reasoning. In physics, after all, some of the most directly practical advances originated with theoreticians who never came close an experiment. But in software engineering the case has not occurred — all the great methodologists have also been programmers and project leaders on large developments — and seems unlikely to occur. Object technology in particular is among other things, an intellectual tool to build large and complex systems; the only approach, in fact, that has attempted consistently and comprehensively to reach this goal. One can master the essential concepts through taking classes, reading the literature, performing small-scale experiments and thinking further, but that is not preparation enough to give good methodological advice. The experience of playing a key role in the building of large systems — thousands of classes, hundreds of thousands of lines — is indispensable. Such an experience must include all activities of the software lifecycle: analysis, design, implementation, and of course maintenance (the final reckoning, at which one recognizes whether the solution adopted at earlier stages stands the test of time and change, or collapses miserably). Analysis experience, or even analysis and design experience, is not enough. More than once I have seen analysis consultants who do their job, charge their fees, and leave the company with no more than “bubbles and arrows” — an analysis document. The Theoretical Basis methodology principle Software methodology rules must be based on a theory of the underlying subject. Practical Basis methodology principle Software methodology rules should backed by extensive practical experience
666 ON METHODOLOGY $19.2 company then has to pick up the pieces and do the hard work;sometimes the analyst's work turns out to be totally useless as it has missed some of the most important practical constraints.An"analysis only"approach belies the fundamental ideas of seamlessness and reversibility,the integrated lifecycle that characterizes object technology,where analysis and design are interwoven with implementation and maintenance.Someone who misses part of this picture is not equipped to give methodological advice. Reuse Having played a key part in some large projects is necessary but not sufficient.In the object-oriented field the Practical Basis precept yields a corollary:the need for practical reusability experience. Among the distinctive properties of the method is its ability to yield reusable components.No one can claim to be an expert who has not produced a reusedO-O library; not just components claimed to be reusable,but a library that has actually been reused by a substantial number of people outside of the original group.Hence the next precept: Reuse Experience methodology principle To claim expert status in the object-oriented field,one must have played a key role in the development of a class library that has successfully been reused by widely different projects in widely different contexts. A typology of rules Next we should turn to the form of methodology rules.What kind of advice is effective in software development methodology? A rule may be advisory (inviting you to follow a certain style)or absolute (enjoining you to work in a certain way),and it may be phrased in a positive form(telling you what you should do)or in negative form(telling you what you should not do).This gives four kinds: Classification of methodological rules ·Absolute positive:“Always do a”, ·Absolute negative:Never use b”. ·Advisory positive::s“Use c whenever possible'”. ·Advisory negative:“Avoid d whenever possible”. The requirements are slightly different in each case. Absolute positives Rules of the absolute positive kind are the most useful for software developers,since they provide precise and unambiguous guidance
666 ON METHODOLOGY §19.2 company then has to pick up the pieces and do the hard work; sometimes the analyst’s work turns out to be totally useless as it has missed some of the most important practical constraints. An “analysis only” approach belies the fundamental ideas of seamlessness and reversibility, the integrated lifecycle that characterizes object technology, where analysis and design are interwoven with implementation and maintenance. Someone who misses part of this picture is not equipped to give methodological advice. Reuse Having played a key part in some large projects is necessary but not sufficient. In the object-oriented field the Practical Basis precept yields a corollary: the need for practical reusability experience. Among the distinctive properties of the method is its ability to yield reusable components. No one can claim to be an expert who has not produced a reused O-O library; not just components claimed to be reusable, but a library that has actually been reused by a substantial number of people outside of the original group. Hence the next precept: A typology of rules Next we should turn to the form of methodology rules. What kind of advice is effective in software development methodology? A rule may be advisory (inviting you to follow a certain style) or absolute (enjoining you to work in a certain way); and it may be phrased in a positive form (telling you what you should do) or in negative form (telling you what you should not do). This gives four kinds: The requirements are slightly different in each case. Absolute positives Rules of the absolute positive kind are the most useful for software developers, since they provide precise and unambiguous guidance. Reuse Experience methodology principle To claim expert status in the object-oriented field, one must have played a key role in the development of a class library that has successfully been reused by widely different projects in widely different contexts. Classification of methodological rules • Absolute positive: “Always do a”. • Absolute negative: “Never use b”. • Advisory positive: “Use c whenever possible”. • Advisory negative: “Avoid d whenever possible
$19.2 DEVISING GOOD RULES:ADVICE TO THE ADVISORS 667 Unfortunately,they are also the least common in the methodological literature, partly for a good reason(for such precise advice,it is sometimes possible to write tools that carry out the desired tasks automatically,removing the need for methodological intervention),but mostly because advisors are too cautious to commit themselves,like a lawyer who never quite answers“yes”or“no”to a question for fear of being blamed for the consequences if his client does act on the basis of the answer. Yet such rules are badly needed: Absolute Positives methodology principle In devising methodological rules,favor absolute positives,and for each such rule examine whether it is possible to enforce the rule automatically through tools or language constructs. Absolute negatives Absolute negatives are a sensitive area.One wishes that every methodologist who followed in Dijkstra's footsteps had taken the same care to justify his negatives as Dijkstra did with the Goto.The following precept applies to such rules: Absolute Negatives methodology principle Any absolute negative must be backed by a precise explanation of why the author considers the rejected mechanism bad practice,and accompanied by a precise description of how to substitute other mechanisms for it. Advisories Advisory rules,positive or negative,are fraught with the risk of uselessness. It is said that to distinguish between a principle and a platitude you must consider the negation of the property:only if it is a principle does the negation still make sense, whether or not you agree with it.For example the often quoted software methodology advice"Use variable names that are meaningful"is a platitude,not a principle,since no one in his right mind would suggest using meaningless variable names.To turn this rule into a principle,you must define precise standards for naming variables.Of course in so doing you may find that some readers will disagree with those standards,which is why platitudes are so much more comfortable;but it is the role of a methodological advisor to take such risks. Advisory rules,by avoiding absolute injunctions,are particularly prone to becoming platitudes,as especially reflected in qualifications of the form"whenever possible"or,for advisory negatives,"unless you absolutely need to",the most dishonest formula in software methodology. The next precept helps avoid this risk by keeping us honest:
§19.2 DEVISING GOOD RULES: ADVICE TO THE ADVISORS 667 Unfortunately, they are also the least common in the methodological literature, partly for a good reason (for such precise advice, it is sometimes possible to write tools that carry out the desired tasks automatically, removing the need for methodological intervention), but mostly because advisors are too cautious to commit themselves, like a lawyer who never quite answers “yes” or “no” to a question for fear of being blamed for the consequences if his client does act on the basis of the answer. Yet such rules are badly needed: Absolute negatives Absolute negatives are a sensitive area. One wishes that every methodologist who followed in Dijkstra’s footsteps had taken the same care to justify his negatives as Dijkstra did with the Goto. The following precept applies to such rules: Advisories Advisory rules, positive or negative, are fraught with the risk of uselessness. It is said that to distinguish between a principle and a platitude you must consider the negation of the property: only if it is a principle does the negation still make sense, whether or not you agree with it. For example the often quoted software methodology advice “Use variable names that are meaningful” is a platitude, not a principle, since no one in his right mind would suggest using meaningless variable names. To turn this rule into a principle, you must define precise standards for naming variables. Of course in so doing you may find that some readers will disagree with those standards, which is why platitudes are so much more comfortable; but it is the role of a methodological advisor to take such risks. Advisory rules, by avoiding absolute injunctions, are particularly prone to becoming platitudes, as especially reflected in qualifications of the form “whenever possible” or, for advisory negatives, “unless you absolutely need to”, the most dishonest formula in software methodology. The next precept helps avoid this risk by keeping us honest: Absolute Positives methodology principle In devising methodological rules, favor absolute positives, and for each such rule examine whether it is possible to enforce the rule automatically through tools or language constructs. Absolute Negatives methodology principle Any absolute negative must be backed by a precise explanation of why the author considers the rejected mechanism bad practice, and accompanied by a precise description of how to substitute other mechanisms for it