$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