in reply to rewrite: in literature and in coding

Tanktalus: I don't know, the hard part is usually figuring out what you want to do and how to do it. Proper coding methods will leave you with a number of interlocked subs and modules, each of which takes specific input and produces specific output. You might need to modify your wrapper some and add (or remove) subs / modules, but assuming you wrote down a synopsis of what your wrapper does, and documented proper input and output for each sub, rewrites should be relatively easy no matter how long it's been. They're only difficult if you slap everything together into one long mess and don't test or document anything.

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

  • Comment on Re: rewrite: in literature and in coding