This exchange of email seemed better than the "tidied-up" version we attempted to make, so here it is as it was... YMMV.  --AlistairCockburn
----
MysteriousStranger-- << I am interested in your own experience in the UML. Did you ever develop a COM or CORBA application when you use the UML technique? >>

AlistairCockburn-- <<The first thing to be clear about is that UML is not a technique, it is "only" a set of drawing standards.  I attach here a conversation I had with another consultant about this topic recently: 
>>

MichaelHill-- << Question:  Aside from the threadmode commentary on UML, do you agree that  this page fairly represents BigDesign principles on their own terms?  Why  doesn't this represent a reasonable assessment of say, OMT? >>

AlistairCockburn-- <<BigDesign and OMT are almost orthogonal to each other.  OMT is a drawing notation.  it is not a methodology, and it does not make prescriptions about when, where, and how much you draw.  OMT is completely compatible with think a little, draw a little, code a little, which is not BigDesign.  In fact, I think Booch himself has published the advice, think a little, draw a little, code a little.  He is certainly aware of and in favor of iterations, spirals, prototyping, increments, etc. And so is Rumbaugh, I have heard him talk of it himself.

Now, Booch is also a proponent of having an architecture.  He has concluded that the prime cause for failure across a set of projects he visited was absence of architecture.  he would probably go on to explain how you get an architecture without doing what the wiki ists call BigDesign.  But then again, I find the wiki BigDesign discussion is not anchored, and wanders around.

There is on wiki a strange association of drawing (OMT, UML) and BigDesign, a confused association I don't find in most places.  

The starting point for the wiki BigDesign and BigDesignUpFront seems to be that it is Evil.  Just what it is that is Evil is not yet described, but the description needs to be something that every sensible programmer will understand is Evil.  This is the backwards way to start.  The way to start is to describe One Way Of Working, and then label it, and then look to see to whom it would appear Evil, and to whom not.  I am not sure if what you put up there is really BigDesign, or if there is a BiggerDesign that is what the readers are wanting to object to, or if it is BiggerDesignUpFront, or ...     What about BigDesignInTheMiddle?  Is that evil?  How about BigDesignScatteredThroughout?  Evil to whom, and on what grounds?

I think it is safe to say that there are people who really believe that one should sit and think for as long as possible before starting, that you can think through the worst of the problems, and that it saves time to do so, and that in fact it is truly dangerous not to.  There is an overlap with people who think that writing everything down is important.  I disagree with the second sentiment more than the first sentiment.  I have seen people try to do iterations within increments, documenting everything assiduously as they go.  They never got a chance to go very far. 

Even C3 did a domain architecture at the beginning, and still stick to it (bins and lines and whatnots, recall?).  And I believe having that domain architecture is indeed critical to the success of their project, otherwise they could not keep all the details in place.  That was DesignUpFront, just not BigDesignUpFront (whatever that means).

I just visited a smart lady in Wash DC, who has been at this for years, mostly for big DoD contracts.  She accused me of not trusting ModelBasedDevelopment, because I bashed CASE tools in my book.  It seems she wants to draw instance diagrams, and interaction diagrams, more than class diagrams.  I think doing that is great!  Yet she had somehow confounded whether the drawings were done on line or on paper with whether they were getting drawn. She was terrified people would actually draw the drawings by hand, then scan them into the email system and simply paste them into documents.  I can't understand why she is afraid of that, but she thinks drawing on paper is not "model based".  beats me.

Actually, I do understand.  I have spent years untangling the degrees of freedom of all these things, and most people haven't.  To most people, saying CASE tools is the same as saying OMT is the same as saying BigDesignUpFront is the same as saying Waterfall, .....
>>

MichaelHill-- <<Let's go with the two principles you mentioned, 1) write everything down permanently,
and 2) think really hard before moving, and let me throw in another, 3) work
in long cycles.  Call these 3 separate and separable continuums, make a line of each, and put on
the lefthand sides: permanently-write-nothing,
code-as-soon-as-you-can, and make-cycles-as-short-as-you-can, and on the
righthand side put permanently-write-everything, code-as-late-as-you-can,
and make-cycles-as-long-as-you-can.

Your main point is well taken:  No drawing (or documenting) language, e.g.
UML, actually represents a position on any of these 3 continuums.  The first
continuum measures the intended permanence of our drawings, not really the
presence or absence of drawing as a tool.  Somewhere on the wiki I indicate
that I draw practically everything in UML, (or in truth, old-style Booch,
which I like better and am more comfortable with), yet I certainly would
push the permanently-write-everything control to the far far left.  I
routinely draw ten diagrams a working day and throw them all away.  I rarely
even do a File|Save inside Rose.

It's been a while since I read Booch or Rumbaugh either one, so I'll take
your word for it that neither of them is advocating a particularly rightward
triplet of settings.  Probably, and for all I know, *no* theorist is
advocating a big rightward approach.  But the positions I see out in the
field have all three settings pushed as far to the right as they can go.
(Okay, that's nonsense:  waterfall is abandoned in almost all serious shops,
so make-long-cycles really maxes out to cycles measured in quarters.)  Does
that rightward bent have a name?  That's one question, but maybe a little
irrelevant:  Named or no, it seems prevalent, and I'm not trying to
caricature here.

An aside, though:  if the three banditos are not advocating a particular
rightward setting, they're not arguing against one, either.  Anyone who
would seek to 100% document their work using UML is practically guaranteed
to push the other two slides to the right also.  UML is as big as C++, and
considerably less rigorously defined.  As a sketching tool, it's too much
like a programming language, and as a programming language, it's too damned
sketchy.

When I go onsite to teach (C++ and MFC), the teams almost inevitably give me
the same messages, sometimes openly and sometimes in private:  we hate our
work, we spend all of our time managing process, especially documenting, we
spend little of our time coding, we consistently miss our deliverables and
are therefore consistently behind the marketing eightball, and so on.
Almost all of these teams have the three setting to the far right.
>>

MysteriousStranger-- <<Thanks very much. I've looked over your letter. It seems that I've
understood more from an interaction between two people than from all
books I'd read>>

-----------------------

Hmm, dare I dip my toes back in this cold water? FWIW, there's three reasons I really don't like BigDesignUpFront or anywhere else:

	* It ignores the ScientificMethod.
	* It makes Big Models, and I invariably find BigModelsAreUseless
	* AjiKeshi

I like architecture just fine. I can't get by without it. But architecture is a little model that defines a paradigm, not a big model that documents code. The reason I see UML confused with BigDesign is that, whatever Grady Booch says, the tool he sells as one of the UmlCaseVultures encourages the development and maintenance of Big Models because of all that full-cycle code-generating reverse-engineering malarkey. 

More than that, when you dig the RationalUnifiedProcess, which is a methodology, not a notation, you find 2 whole phases of BigDesignUpFront that have to be completed before you can code anything bigger than an architectural prototype. I can see how to adapt this to a full iterative context, and this is just what I'm doing, but I don't believe that's what it's recommending, or else I'm reading it way wrong - you tell me. --PeterMerel

''I'm wondering whether the RationalUnifiedProcess is well-enough defined so that we can use it as an example of BigDesignUpFront, or whether the entire BigDesign discussion is in trouble because it's talking about something with no real definition other than "I wouldn't go that far". --RonJeffries''

ClassicFusion went BigDesign but EvoFusion doesn't; it is possible to think that the ThreeAmigos don't any more either, even if RUP does (huh?). Someone was suggesting, I think (lost it) that TomDeMarco still goes BigDesign, but I don't know if DeMarco has the mindshare he once did; so perhaps Ron's right and BigDesignCritique is flogging a dead horse? --PeterMerel

----
While it is true that the OMT is just a drawing notation, not a methodology, OMT is so comprehensive a notation that it seems to lead in a BigDesign direction. Imagine you're solving an IQ-test question. Row one contains Big Design and Little Design. Row two contains CRC cards and OMT. The question says: which item on row two belongs with which item on row one?