I think of the playwrights, novelists and poets who work according to their own deadlines and standards as akin to opensource developers working on their personal projects. They can try different approaches, rewrite code, and recode APIs as much as they like in the pursuit of not only correctness but beauty as well.

One advantage writers (at least the succesful ones) have is editors. A good editor is a treasure who will take your work and trash awkward or redundant passages, suggest new directions, and spur you on to do work beyond what you thought possible. Pair programming in XP and user feedback in opensource projects can emulate this, at least in the details, but you can't beat a dedicated editor for attention to both the forest and the trees.

Can a writer really refuse to show his/her work when under contractual deadlines? Is this really that different from the creative output of a software developer? Once the work has been released into the world, literary authors don't go back to rework their works too often, I imagine, but neither do they build on previous works the same way as software authors.

In the course of writing a piece of code, I have not infrequently had to rewrite the code multiple times during the initial phases (design, coding, unit testing), and less frequently during later phases (integrated testing). But if that's what is required to get the functionality correct, that's what I do. It's not that I tell my manager that's what I'm doing, nor that I don't tell my manager. It's just what I believe is the fastest way to get an accurate, reliable piece of functionality.

Larger (subsystem+) rewrites are much more rare. But, again, if that's what is required to get reliable, functional code, then that's what I do.

It is important, though, that you've learned from previous mistakes before going through a rewrite. In the initial phases, this is pretty trivial: you just wrote the non-working code, so rewriting it immediately should naturally incorporate what you've learned. For later phases, where there may have been a time span of a week, a month, or even a year, between write and rewrite, this can be much more difficult.

Once the work has been released into the world, literary authors don't go back to rework their works too often, I imagine . . .

On the contrary, different printing runs of the same book may have subtle additions. Often, it's just spelling/grammar corrections that weren't caught the first time around, but it could potentially be any sort of changes. IIRC, Aldous Huxley greatly expanded "Brave New World" in later editions of the book.

Even if they don't get a chance to make a change, many creators wish they could. I usually look at writings of mine 6-18 months later and think the whole thing is crap.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

As to can a writer really not release his work until he's ready - no, not really, unless he or she is already an established name, and can dictate the terms of a contract.

But one key difference is that _every_ writer is expected to do rewrites. Typical development (as I judge from talking to my writer friends) is something like this: You write a first draft, getting the ideas on the page. Some writers do it mostly as one pass, while some continually go back and revise earlier sections as the story demands change. But once it's done, you do a little dance, and go have a nice dinner, and the next day you go through it again, identify clunky sections, and do a bunch of rewriting. And only then do you consider it ready to send in to your publisher. (Selling the book is a different process, that tends to go off of outlines and rougher chapters, particularly for new authors, which I'm ignoring.) Then, the editor reads it, and sends back the redline version, which could call for extensive rewrites. Their ideas and feedback could be quite helpful, so usually there's another rewrite period. There might be another round of feedback and polish if that was extensive. And then, finally, it hits shelves.

So, I'd say a typical novel has 2-4 rewrites before we see it.

Code, on the other hand, tends to have the first pass. You might be lucky enough to rewrite some earlier sessions if your needs and understanding of the problem change. If you're really lucky, you'll get a code review and have time to make some changes. (The editor step.) And then it's live, and you get to do bug fixes for eternity, but rarely a real rewrite.

I don't think that the typical novelist development model really is well suited to software, mind you - the gains of a full rewrite process before the software is released is not nearly as substantial as for a novel, and the cost of patches is much less for software than for a novel (especially logistically) - but the basic moral is there. The fiction industry understands the value of revision and review, and the software industry needs to as well.

-- Kirby, WhitePages.com

This process doesn't sound much different from software: you design (rough outline), get everyone to agree to the design (try to sell idea to publisher), then fill in the holes (write the code), go through code review (editors), and then, once everyone is happy, check in to your source code control system (hits shelves).

True, not everyone goes through every step. But that may be because writing software is such a young business compared to authoring fiction that people think they can still take shortcuts and get quality output. You can't.

I would say yes even while under contractual obligations a writer could refuse to show their work. This would depend on the contract i.e. if the contract was merely a publishing contract that dealt with the next 4 novels x writes will be published by y. However, if a writer is writing for a magazine or newspaper it is highly likely deadlines will require stories to be writen and turned in in a set period of time. I would also have to say that writing and coding are way different. You can never be certain what is "good" when writing but in coding if it works correctly and meets the clients needs then rewriting is unnecessary even if it would be desireable.

So, just my .02 writing is an imprecise science at best because it is based on audience reaction where as coding is based on specifications

It can be difficult, however, to lock down what you're trying to do well enough to compartmentalize properly in a first draft. You know the programming methodology, and the client has a general idea of what he wants, but there's generally several rounds of:

Client: "I want x"
You: "It isn't really possible to do x, but what about y or z?"
Client: "Ok, z then."
You: "Good. You can do z using methods a, b, or c."
Client: "b sounds good."
You: "b is perhaps the most elegant method, but it will take more time and money. Looking at your situation, c might be better."
Client: "But I have to have b. There's a hidden requirement j that I forgot to tell you."
You: "Oh boy..."

I liked the fact that a writer can refuse to show people his/her work until he/she is satisfied, and typically after many re-writes. Sometimes I wish that I could have that luxury when writing code...

Count your blessings (that Perl code is in enough demand that there is someone who won't wait for perfection).