Re: OOP/OOD Philosophy

"Robert C. Martin" <unclebob@xxxxxxxxxxxxxxxx> wrote in message
news:j5elc1t6jakj9cg1h9dbm70r6uv9ik2n7t@xxxxxxxxxx
> On Mon, 4 Jul 2005 13:10:22 -0700, "Nick Malik [Microsoft]"
> <nickmalik@xxxxxxxxxxxxxxxxxx> wrote:
>
>>Note: I did not say that "Agile" is incompatible with "design." I believe
>>it is incompatible with "Big Design."
>
> Not quite. Agile methods involve much more design than "Big Design"
> methods. However, the design is done on a different schedule. Design
> is taking place all the way through the project, at every iteration.
> This design is no less rigorous than a big design up front. Indeed,
> it is *more* rigorous, because each design decisions is documented by
> a series of unit tests and acceptance tests that must be written
> *before* the code that makes them pass.

Alas, I'm guilty of attempting to imply a term without doing a good job of
providing a meaningful definition. The acronym BDUF is a bit off-putting in
conversations where the other participant is intentionally ignorant of agile
concepts. Please forgive my lack of clarity.

>
>>I hope to have made it clear that I
>>believe that you can (and should) perform MDA on an agile project. I've
>>done it. I've seen it done.
>
> MDA is perhaps different from what you think it is. MDA is the notion
> of drawing diagrams and then automatically converting them to code
> using some kind of translator. In a true MDA environment you would do
> all of your programming by drawing diagrams.

Yes. Many tools that are being used for this have the ability to be used
many times through the process. You can create the model, hand-modify the
code, and recreate the model from the code. This round-tripping is Very
useful in iterative design processes because each innovation can be
inspected for compliance with the fundamental notion of "does it solve This
business problem?" This keeps with the notion of solving the problem when
it is presented, and not before. As I understand this, this is fairly key
to keeping costs low in an agile environment.

I have done this on some small projects and found it to be a useful
practice. I'm hoping to do more of this in the future, as I believe it
makes the "design conversation" more succinct during the sprint planning
stages. It also helps to find the "outliers" (objects that were created by
programmers who didn't understand the design and just shoved something into
a static utility class to get it out of the way). These become stories to
refactor them in the coming iteration.

>
>>It appears that you've been told that agile
>>methods leave no room for design. My guess is you heard that from a
>>self-proclaimed XP evangelist. I rank them a notch below most TV Shopping
>>Channel pitchmen in their respect for science, impartiality, or
>>fundamental
>>integrity.
>
> Nick, I'd like you to name some names. Who are these self-proclaimed
> XP evangelists who are a notch below...?

Certainly not you, Robert. The members of the original Agile Alliance have
(mostly) done a good job of using words that are fair and partial, if
sometimes a bit strident. However, there are many "hucksters" out there
that have read half of a book on XP and then go out preaching about XP with
no more understanding than a teenage high school dropout attempting to
lecture me on the mechanics of the supply chain. I have come across some of
them. One offered me a job (which I turned down). Others have underbid me
(when I was in the consulting business). Others have vociferously
challenged me when I dared mention UML when discussing the notions of OO
design. They were not credible, and they gave "agile" a bad name.

There are many people making money off of agile methods that are not as
upstanding as you are, Robert. Surely, you have run across some of them
yourself. Naming names will only get me into a libel suit. Their goal is
to make money, not improve software.

>
> Frankly I don't see any. There are some folks out there who's
> enthusiasm sometimes gets the better of them, but that's a whole
> different matter.

see above

> On the other hand, there *are* people out there
> making utterly ridiculous negative assertions about XP and Agile.
> Some have even written books about how bad XP is. It's clear that
> these people have never done XP, don't know much about XP, and don't
> care to know anything other than that they don't like it. They simply
> bash for the joy of bashing. THESE are the folks who remind ME of TV
> pitchmen.

When I first heard about agile methods, I was very dubious. I decided that
I had two choices: to get defensive or to read more about it. I took the
latter. I've learned a lot and I find myself explaining agile methods to
people who have mistaken notions about it. I've used agile methods more
frequently in the past few years and I expect that will continue. While I
am a scrummaster, I don't pretend to be an expert on agile methods. I defer
to those who have done more than I have, and I glide under the noise, being
a change agent along the way. On the other hand, I have found that simply
using individual methods as "best practices" (which they demonstrably are)
gets you in the door with people who otherwise scream and run for cover when
you use the term "agile" in their presence. There are ways to change
organizations that are subtle, but powerful.

I agree that the noise out there is not rational. I agree that there are
folks who oppose agile methods with an almost hysterical response mechanism.
I posit only that there are a few folks on the other side as well. We need
to "lower the heat and turn up the light" in all our conversations,
recognizing both the good and bad, the known and the unknown, in order to
achieve real change in this crazy profession we've chosen to practice.

I'm on the side of reason.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


.

Relevant Pages

  • Re: OOP/OOD Philosophy
    ... The methodology is well-documented. ... It is agile because the term 'extreme' as been so over-exposed that the ... > in which you do design can enable the team to respond to change, ... > that surveys of users have shown that nearly 50% of all features in a BDUF ...
    (comp.object)
  • Re: OOP/OOD Philosophy
    ... Clearly, I'm not going to convince you, on a newsgroup, that Agile methods ... it is incompatible with "Big Design." ... programmer helping programmers. ...
    (comp.object)
  • Re: OO Software Project Entropy Question.
    ... > intelligent engineers hardly take prior design as written in stone]. ... Without Agile practices, software engineering projects occupy a spectrum, ... Agile projects rise above that spectrum. ... Debugging pushes behavior back and forth, ...
    (comp.object)
  • Re: Call for participation: What types of organisations adopt agile methods?
    ... I can certainly see that there can be projects where the requirements are easily knowable upfront, and thus where agile iterative requirements-gathering isn't needed. ... No problem - you write them all on story cards at the start, and then the project manager negotiates a bunch of them with Agile Patricia every iteration. ... Waterfall Patricia was able to draw up a big design upfront, based on the whole set of requirements. ... Reason 1 is absolutely true, and highly important in practice, but it's kind of a meta-reason. ...
    (comp.lang.java.programmer)
  • Re: how many bugs do you find and correct during TDD?
    ... I have worked in both agile and design up front fashion. ... I have not built planetary weather pattern modeling software, ... of all, a big corporate payroll. ...
    (comp.object)