Re: OOP/OOD Philosophy

On 4 Jul 2005 11:03:01 -0700, "krasicki" <Krasicki@xxxxxxxxx> wrote:

>It is agile because the term 'extreme' as been so over-exposed that the
>audience for this stuff evaporated.

Their is a grain of truth to that statement, but only a grain. I
called the meeting, I was there, I know. The name "agile" was
selected to represent a group of similar methodologies that included
Scrum, FDD, DSDM, Xtal, and XP. During the discussions we did mention
that the name "Extreme" was creating both positive and negative
reactions, and we wanted something a little closer to the core
motivation.

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.

>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.

>Numerous OOD methodologies handle change much better than the agile
>proponents will have you believe.

Facts would be useful here. My experience has shown that agile
techniques strongly prepare software for change. 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.

>The agile practices are no more
>adept at change than anything else.

Again, facts would be useful. 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 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.

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 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*.

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

>This is not responsible change management. This results in chaos and I
>have seen it in profoundly big companies whose platitudes, awards, and
>self-serving hype disguise the fact that beneath the covers employees
>were agile enough to artificially meet deadlines to cash in on bonuses
>while the quality of the software remains dubious to this day.

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.

>Agile to me means slippery and dodgy - I don't like it and it is
>unacceptable in mission critical scenarios.

You have put the name "Agile" on something that is not Agile. Agile
does not mean "hacking". Agile does not mean running off half-cocked.
Agile does not mean slippery and dodgy. Agile means moving in very
small, determined, disciplined steps with a mass of verification at
each step, and lots of feedback from previous steps.



-----
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
.

Quantcast