sundialsvc4: First, please let me say that I pretty much always enjoy reading your various mediations, expositions, etc. Thank you very much - they are often thought-provoking and usually educational, and I appreciate the time and the effort you put into them.

In this case, though, I have to say that I disagree with you very strongly. This is going to be rather long and somewhat impassioned; please pardon. As my excuse, I offer the fact that I *often* have to go through the short-but-full-of-sound-and-fury version of this with clients, and have in fact just done so (last night.)

I worked on a Perl app for a couple of months, then wrote all the code in a week.

What made the "couple of months" before that week not scrap? What made the "several revisions" and the "discoveries" not scrap? Is it simply the fact that you weren't writing code when that was happening? Some people "think better on paper", or at the keyboard, at some level of the development process. I certainly don't need to experiment with, say, 'grep' or 'map' to know how they work, so I'm not going to do that. I don't have any doubts about writing a subroutine, or figuring out what it will return, etc., etc., etc... but there's *no* way that I can tell, without writing some code and putting it through the mill how my client, or the people that work for him, are going to react to and interact with an interface that I'm going to use as the front end to the app that I've been hired to write. There's *no* way for me to predict that, once I've followed all the specs that were written down and finished all the coding, the client's not going to look aghast and say "but of course you needed to make sure the numbers were all written out as words... in the Tarahumara language. In 144-point Comic Sans, in transluscent blue with a slight hint of iridescence, and displayed on multiple monitors - one per letter. It's standard in our industry!"

The one thing I've learned over the many years of dealing with clients is that Revisions Will Happen - at every single level of the project, including and especially those that you think you've nailed down and cast in stone. As a result, I make it explicitly clear (some might say "to a ridiculous degree") that it is the client's job and proper expectation to pay for those changes. Yes, including my learning curve - if that's what you want to call it. I almost don't care about the rest of the agreement, but that one part must be understood and signed off on.

That "learning curve", you see, is inevitable. It is impossible for me to know every single detail of every single type of business that I code for - and I am certainly not going to spend my (unpaid) time learning those details. That's really what this is about: who pays for that "wasted" time? To me, the answer is "the client". When they hire a new employee - say, an accountant - they inevitably have to retrain that accountant (and pay for that retraining time) to teach him the specifics of being an accountant in the ferret-shining industry rather than in the weasel-polishing trade that he came from. No one ever argues about this; it's a standard business expense.

In our business, however, you're supposed to intuit all of that data - because we programmers are so frightfully smart that, well, we should just be able to do that.

Um... HELL NO. I always gently-but-firmly shove that notion right back down the client's throat as soon as it comes out of one.

I was not “learning as I went.” First, I learned; then, I went.

Who paid for that learning time? If it was your client, you still, by your definition, "wasted" their money - no matter how you structure that explanation. If it was you... but then, I very much doubt that it was, or that it's even possible.

-- 
Education is not the filling of a pail, but the lighting of a fire.
 -- W. B. Yeats