From: Universe Date: 2001-12-15T17:50:41+09:00 Subject: [ruby-talk:28605] Re: John Roth dolt ( Re: A challenge to proponents of Unit Testing. ) "David B Lightstone" wrote: >"Ron Jeffries" wrote in message >> brangdon@cix.co.uk (Dave Harris) wrote: >> > >> >I mostly agree with this, and it bothers me that XP advocates don't seem >> >to pay much attention to coverage tools. >> The short reason, and I don't mean it to be curt, is that we are >> paying attention to defect detections, not to coverage. When defects >> slip through the net, we improve the net. >Don't you kind of have a chicken and an egg situation here. Can't >observe a defect that slips thru the net without either conducting >an observation (aka test) or doing a code analysis. As near as I >can tell analysis only occurs when a defect is detected or >someone declares a need for a refactoring. Over the past few days it's become clearer than ever that XP is a "merchant's methodology" and the above position on defects, strengthens that. In the mid-90's I began to state that the reason, RMartin et al backed certain deleterious development and coding practices was because overwhelmingly most of them nearly always do "back end", consultant programming. That they were unaware of what really goes actually goes on in most large organizations wrt software development. RMartin himself agreed. Less than 2 years ago RMartin et others here began to advocate XP methodology. At the time I said that their approach "formalized" their aforementioned "back end" programming perspective. Now, I'm surer than ever that XP is a "merchant's methodology". a.) YAGNI - the simplest thing that works fits a "merchant's methodology" perfectly. Get the minimum code out of the door that works and fills our coffers soonest. Why add flexibility, extensibility and robustness when we can get code out now, get our money now, and let others, 2, 3, 5 years from now, worry about any problems later? XP doesn't put an emphasis on, nor checks, as Jeffries confirms above, for flexibility, extensibility and robustness. Just defects in use cases not being met. When they are met, they ship. The sooner to fill the coffers. b.) RMartin now even gives at best short shrift to key techniques aimed at optimally loose coupling between modules and optimally high cohesion within modules. This of course was confirmed recently by his anti-encapsulation remarks. Not necessarily anti-LoD, a major way to achieve loose coupling and high cohesion, but in other remarks on other factors affecting encapsulation. It's gotten to the point where I can no longer say what distinguishes us is that I see OO as primarily taking advantage of the power object abstraction and object abstraction collaboration whereas they emphasize that OO is about dependency management above all else. Not with their very public pooh poohing of OO encapsulation issues - striving to have public interface with hidden, or private implementation. >> Coverage is interesting, and >> some XP teams are using it. I think it's a good tool for learning how >> to test. In my opinion, it's secondary to the goal of producing code >> that is [sufficiently] defect-free. Why go around looking for defects when we can make some money now if the feature works fairly well? It's a doggone shame what XP is doing to customers, to the good growth and nurturing of the wonderful concepts and practices of genuine OO, and to the minds of programmers, new and not so new. It's a doggone shame what a "merchant's methodology" will do. Elliott -- "Creating proper abstractions and abstraction models, with loosely coupled and highly cohesive modules are sine qua non of great modelling and software programming." @Elliott, 2001 Celebrate Modelling! *^* 3w.radix.net/~universe