You seem to think my day-job practices are a lot more formal than they are. :-) No, I'm talking about an agile use of UML. I've never been in a software process where we diagrammed everything and then programmed it. The two ways I've used UML are as an alternative visualization of code (like Together's class diagram, which is round-trip engineered from the code, so designing and coding are inseparable activities), or as an irregular punctuation of the normal, iterative story/code/refactor cycle -- those moments when you say "OK, hold on, let's visualize what we've got here at a higher level", and draw on the whiteboard. For a few minutes. Or at most, for a class library likely to be used a lot by a distributed team, I might whip up a GIF of UML for a few key relationships and stick it on the project wiki.
It's the whiteboard situation I'm talking about -- I feel like I'm at a point in my novel which is analogous to the point in software development where you say, "hmm, let me sketch this out for you," and am missing my usual tools. Never mind the entire robust vocabularies of UML and Design Patterns -- I feel like I'm missing primitive notions on the order of "class". (As Delany observes in About Writing, the vocabulary of "character, plot, theme, setting" is a vocabulary (emergently) designed for literary criticism, and is not well-adapted to actually writing.)
So I actually am saying "until you can see it", with a visual modelling language being one of the ways I am used to (only at certain moments) being able to see, rather than "until you have a formal diagram" (which would imply that 99.9% of my software has no design :-> ).
The idea that because a good way to make software is a series of small iterations, therefore a good way to design a modelling language is a similar series of small iterations, is appealing but I have no idea if it's true or not, and I'm wary of cross-domain analogies. The false analogy between software development and civil engineering which dominated process thinking for decades cost untold billions of dollars, after all.
Is it true that "UML evolved from several progressively more formal lineages of informal diagrams"? I'd say UML itself was committee-wrangled from a bunch of formal lineages of formal diagrams, which had been born as formal diagrams.
We're not anywhere near the point in the process where the committees of modelling consultancies (Booch, Jacobson, Rumbaugh et al), smelling the extinction of their way of life, band together to hash out a unified approach. At that point in time their various methodologies were indeed arguably results of an evolutionary process, having been tweaked and tweaked over the years to accomodate various clients.
But I think the idea that they grew up from boxlike sketches with no formal system, gradually formalizing decade by decade, is probably false (though I'd be interested in historical evidence). My sense is there was an informal practice called "here's some stuff", in which boxes represented anything -- actors, modules, features, physical boxes, whatever -- and arrows or lines represented anything -- inheritance, messages sent, things being vaguely similar -- and that was pretty much it until someone came along and, applying totally separate techniques borrowed from other domains, invented flowcharts, or the Booch Method, or any other formalization.
I don't think you get naturally from the naive sketch to, say, the 1982 Booch Method cloud class diagram by iteration, any more than a successful open source project starts with a few lines of code shared between many coders. I suspect that a visual language -- like an open source project, and unlike software development projects in other contexts -- requires a critical mass to start with.
Someone sitting down and creating sendmail or HTML or flow charts and making them good enough to be actually useful to a number of people is a prerequisite for, not a result of, an evolutionary process.
I am drawing boxes of my existing MS. Obviously I wouldnt start writing a novel with a modelling language! (That would be even dumber than starting a software project by drawing a class diagram. At least for the kind of writer I am. I can't even write an outline).
The problem is that all the boxes look the same, and all the lines look the same, and after having drawn the sketch I don't know any more than I did before -- which is precisely my experience of that kind of naive s/w diagram where you draw a box for the server, a box for the user, a box for the message, a box for the data, and a box for the program, and then draw lines between them and stare at it, numbly, wondering what it's trying to tell you.