$19.2 DEVISING GOOD RULES:ADVICE TO THE ADVISORS 669 is not the whole of 4,but A deprived of B,C and D.What is unacceptable,however,is the contrast between a precise,prescriptive rule,and a vague provision for exceptions ("in some situations,the cost may be greater than the benefits"-what situations?).Later in the cited article,an example is shown that violates the rule,but the exception is justified in terms of ad hoc arguments.It should have been part of the rule: Exceptions Included methodology principle Ifa methodological rule presents a generally applicable guideline which may suffer exceptions,the exceptions must be stated as part of the rule. If exceptions to a rule are included in the rule,they cease to be exceptions to the rule!This is why the principle talks about the "guideline"associated with a rule.There may be exceptions to the guideline,but they are not exceptions to the rule if the rule observes the above principle.In "Cross the street only when the traffic lights are red,except if the lights are out oforder",the guideline "cross only on red"has an exception,but the rule as a whole does not. This principle turns every rule of the form"Do this..."into an absolute positive,and every rule of the form "Do not do that..."into an absolute negative. Self-doubt is an admirable quality in many circumstances of life,but not one that we expect to find in software methodology rules.One could almost argue that a wishy-washy methodologist is worse than a brilliant one who is occasionally wrong.The wishy-washy advice is largely useless,as it comes with so many blanket qualifications that you are never sure if it applies to your case of the moment,whereas if you study a methodological precept and decide that you disagree with it,you must try to refute the author's arguments with your own,and regardless of the outcome you will have leamed something:either you fail,and gain a deeper,more personal appreciation of the rule and its relevance to your problem;or you succeed,and discover the rule's limitations,gaining some insights that the rule's author may have missed. Abstraction and precision A common theme of the last few principles is that methodological advice should be precise and directive. This is of course more fully applicable for precise rules than for general design guidelines.When looking for advice on how to discover the right classes or how to devise the best inheritance hierarchy,you cannot expect step-1-step-2-step-3 recipes. But even then generality and abstraction do not necessarily mean vagueness.Many of the principles of object-oriented design cover high-level issues;they will not do your work for you.Yet they are precise enough to be directly applicable,and to allow deciding without ambiguity whether they apply in any particular case.§19.2 DEVISING GOOD RULES: ADVICE TO THE ADVISORS 669 is not the whole of A, but A deprived of B, C and D. What is unacceptable, however, is the contrast between a precise, prescriptive rule, and a vague provision for exceptions (“in some situations, the cost may be greater than the benefits” — what situations?). Later in the cited article, an example is shown that violates the rule, but the exception is justified in terms of ad hoc arguments. It should have been part of the rule: If exceptions to a rule are included in the rule, they cease to be exceptions to the rule! This is why the principle talks about the “guideline” associated with a rule. There may be exceptions to the guideline, but they are not exceptions to the rule if the rule observes the above principle. In “Cross the street only when the traffic lights are red, except if the lights are out of order”, the guideline “cross only on red” has an exception, but the rule as a whole does not. This principle turns every rule of the form “Do this...” into an absolute positive, and every rule of the form “Do not do that...” into an absolute negative. Self-doubt is an admirable quality in many circumstances of life, but not one that we expect to find in software methodology rules. One could almost argue that a wishy-washy methodologist is worse than a brilliant one who is occasionally wrong. The wishy-washy advice is largely useless, as it comes with so many blanket qualifications that you are never sure if it applies to your case of the moment; whereas if you study a methodological precept and decide that you disagree with it, you must try to refute the author’s arguments with your own, and regardless of the outcome you will have learned something: either you fail, and gain a deeper, more personal appreciation of the rule and its relevance to your problem; or you succeed, and discover the rule’s limitations, gaining some insights that the rule’s author may have missed. Abstraction and precision A common theme of the last few principles is that methodological advice should be precise and directive. This is of course more fully applicable for precise rules than for general design guidelines. When looking for advice on how to discover the right classes or how to devise the best inheritance hierarchy, you cannot expect step-1-step-2-step-3 recipes. But even then generality and abstraction do not necessarily mean vagueness. Many of the principles of object-oriented design cover high-level issues; they will not do your work for you. Yet they are precise enough to be directly applicable, and to allow deciding without ambiguity whether they apply in any particular case. Exceptions Included methodology principle If a methodological rule presents a generally applicable guideline which may suffer exceptions, the exceptions must be stated as part of the rule