Re: OOP/OOD Philosophy

On 5 Jul 2005 18:26:36 -0700, "krasicki" <Krasicki@xxxxxxxxx> wrote:

>Robert C. Martin wrote:

>> As for the audience for XP evaporating, I think you need to actually
>> check your facts instead of stating your opinion AS fact. There is
>> still a large and growing audience for XP.
>
>There is still a large and growing audience for the movie, Plan 9 from
>Outer Space. I'm not holding my breath that it will be reconsidered
>for an Oscar.

You are watching too much "House".
>
>>
>> >So, to be honest it is called
>> >agile to remove the tarnish of the extreme labeling AND to emphasize
>> >peppiness rather than dwell on the ever-present short-comings of the
>> >pseudo-methodology.
>>
>> To be honest, you weren't there. All you have are opinions. I have
>> no problem with you expressing your opinions, but I suggest you
>> represent them as opinions as opposed to fact.
>
>The posters here can google the 'fact' that a number of XP proponents
>bemoaned ever calling the methodolgy 'extreme' because it had become
>such a loaded phrase culturally and politically.

Wrong fact. The fact I was disputing was that the audience for XP had
evaporated. It has not.

> Tell me you go into
>conservative insurance, banking, and finacial services meetings
>emphasizing the extreeme nature of your methodology or the
>revolutionary (enterprise) culture shock they entail.

Sometimes, it depends on whether the folks there have developed an
unreasoned fear of the word "extreme".
>
>Who's being deceitful here?

Nobody except those who offer opinions as fact.

>> Facts would be useful here. My experience has shown that agile
>> techniques strongly prepare software for change.
>
>My problem is that they should strongly prepare software for long-term
>production activity because the software conforms to spec and QA.

XP demands that, every week, the software pass tests written by QA and
Business. These tests specify the system both functionally and
non-functionally. They establish exactly the criterion you mention
above; and they do so unambiguously and repeatably.

>There is no reason to predict change if the job is done right.

That is the silliest thing I've seen you write. Even perfect systems
must change as the world changes around them. Indeed, perfection
itself is a moving target. A system that meets all stated
requirements today, will be sub-optimal tomorrow because the world
will change around it. And you know it. Nobody could be in this
business without the truth of that being ground into his or her bones.

>> I have seen
>> significant changes easily propagate through systems that were built
>> using agile techniques. I have also seen non-agile projects falter
>> and stall when changes needed to be applied.
>
>Is this mildly misleading or are we pretending the audience for this
>discussion are idiots?

Neither. It's simply the truth. I suppose that the statement could
be considered misleading because I did not say that I have seen the
opposite. I didn not feel the need to be balanced because I was
simply refuting your Dean-isms that XP leads to Rube Goldberg,
seat-of-the-pants, non-rigorous, systems.

>> >The agile practices are no more
>> >adept at change than anything else.
>>
>> Again, facts would be useful.
>
>Years ago I chased all of you around the proverbial 'fact-checking'
>bush and got nowhere.

"All of us"? Anyway, I'm not sure I understand your point. Let's for
the moment say that your statement is accurate, and "all of us" did,
in fact, avoid the facts. Is it your argument that you are therefore
relieved of the standard you tried to hold us to? In any case, I
don't know what your "years ago" reference is about. As for facts,
there are plenty out there (both positive and negative), if you are
willing to do some due diligence prior to debate.
>
>I agree facts would be useful. After so many years, where are your
>facts?

What would you like to know? I can point you to both successful and
failed XP projects. I can point you to articles written by companies
claiming huge productivity and quality benefits. I can point you to
research studies, both positive and negative.

And, in fact, with a little tiny bit of elbow grease you could find
them yourself, because they are all freely available on the net, and
respond nicely to Google searches.

>> I can provide a simple counter fact.
>> Having a large batch of unit tests and acceptance tests that can be
>> run against the system in a matter of minutes, makes it much easier to
>> make changes to that system simply because it's easier to verify that
>> the change hasn't broken anything.
>
>And what design do you contrast the running system to to know that it
>is doing what it is intended to do? Or is your assertion that the
>running design is infallible?

I presume you are referring to the functional design; i.e. the design
of the requirements. We contrast the running system against the
design specified by the acceptance tests and unit tests.

>>
>> And here's an opinion, backed by a lot of observation and experience:
>> Writing tests first forces a design viewpoint that strongly encourages
>> decoupling, and that therefore fosters change.
>
>My goal is not to foster change. And bad tests, testing faulty
>assumptions yield successful test results. Without a well documented
>design that exposes such flaws you have no metric to evaluate the
>quality of what you are doing. But let's not dwell on quality.

Tests *are* documents. Bad tests are bad documents. Bad documents
improperly specify the system. Executable tests, written in two forms
(unit and acceptance) are a very effective way to eliminate most bad
specifications.

>> Finally, here are some other observations from various teams that I
>> have coached. Customers are very happy that their input is heard
>> early and often. Executives love the fact that real progress is
>> measured on a regular (weekly) basis, and that stakeholders are
>> providing feedback in real time. All these things promote change
>> IMHO.
>
>What promotes confidence that the thing works correctly? Bells,
>whistles, and favorite colors?

Users observing and using the system from iteration to iteration, and
release to release, while providing continuous feedback.

>> >What agile sells as response to
>> >change is really immedite gratification.
>>
>> There is nothing wrong with immediate gratification so long as nothing
>> else is lost. Indeed, so long as nothing else is lost, immediate
>> gratification is better than deferred gratification. The evidence
>> suggests that nothing else is lost. Indeed, the evidence suggests
>> that the systems turn out *better*.
>
>What evidence and how was this evidence accumulated? All billable
>hours accounted for?

I was thinking specifically of the work we've been doing on FitNesse,
and the work I've seen on JUnit, and Eclipse, as well as the systems
that I have seen in my role as a consultant and coach.

>> This shouldn't be a big surprise. Any control system works better
>> when you shorten the feedback loops.
>
>Only if the feedback makes sense.

That statement gives you an opportunity to say something concrete as
opposed to amorphous disparagements. What, in particular, about the
feedback loops in XP, doesn't make sense? I suggest you do a bit of
research on just what those feedback loops are, and what control
mechanisms XP employs around those feedback loops.

>> Agile Methods are NOT a mad rush to functionality. They are not
>> dotcom stupidity. Indeed, the agile methods value high quality code
>> and high quality designs more than any other methods I know of.
>> Consider rules such as "no duplicate code", "write tests before code",
>> "Don't let the sun set on bad code", etc, etc. There are very strong
>> values that are backed up by disciplines.
>
>Parse the sentence. Everything you value is code-centric. Open your
>mind to OOD.

I agree that I put a lot of value on code. Code is the medium in
which I work, and in which all software systems are eventually built
(by definition). As such, I think that it is very appropriate to
value code. Not that I don't value requirements, I do. Indeed, I put
a lot of research effort into finding better ways to gather, express,
and refine requirements (e.g. www.fitnesse.org).

Open my mind to OOD? I've been writing books and articles about OOD
for over ten years. I was an early adopter, and have worked hard to
advance the state of the art. I think my mind is open to OOD; though
I am always ready to learn something new.

But I'll turn this around on you. Open your mind to XP. For a very
long time you have posted negative statement on this newsgroup that
show that you know very little about it.

>Your argument is not compelling today any more than it was many years
>ago.

Unfortunately yours are no more informed than they were years ago.



-----
Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
.

Relevant Pages

  • Re: OOP/OOD Philosophy
    ... >It is agile because the term 'extreme' as been so over-exposed that the ... The name "agile" was ... As for the audience for XP evaporating, I think you need to actually ... All you have are opinions. ...
    (comp.object)
  • Re: New Website Design
    ... Thanks for your honesty, I appreciate all opinions. ... black and white art with colour accents but your design has ... I want the photos to stand out and not be ...
    (uk.rec.walking)
  • Re: Website for Comments and or Suggestions
    ... My business team ... translate to html well. ... Look, I am not an expert web designer, and my opinions are just that. ... Here are two links that might help in planning the design of your site: ...
    (microsoft.public.publisher.webdesign)
  • Re: Website for Comments and or Suggestions
    ... This is for Publisher webdesign. ... translate to html well. ... Look, I am not an expert web designer, and my opinions are just that. ... Here are two links that might help in planning the design of your ...
    (microsoft.public.publisher.webdesign)
  • Re: Something to consider...
    ... I am saying that there are differing opinions on everything and a person ... admit to pro-administration prejudice ... ... proving that anti-Obama people are his audience as he sees it ... ... "Failing economics" is strong language, ...
    (rec.outdoors.fishing.fly)