I worked on a Perl app for a couple of months, then wrote all the code in a week. It was a matter of going page by page and writing each routine as-specified. And, mind you, it felt a bit strange not to be “figuring it out and...” But the code deployed, was used frenetically by lots of people almost at once, and it never had a single problem report logged against it. It works.

Too bad you just lack the imagination that if X works for you, Y actually may work for someone else (with Y being "different developers", "different company", "different product", "different customers"). I just don't buy the "X works for me, so Y must suck".

My customers are saying "XYZ may become big - can you do a small, no bells-or-frills implementation we can play around with"? Half of those pilot projects are canned ("no, isn't what we want", "is what we want, but doesn't actually give us more revenue", "too hard to sell", "we have different ideas now"). Half of the rest are shelved, to maybe tried later again. The rest is developed further ("we now also want an interface to manage it, instead of typing in database statements", "we want to control who gets access to it", "can we have it in green?"). Successful projects (and by definition, a project cannot be successful unless it has the operational data to back its success up) may be developed further. Oh, and what's a success now may no longer be a success 6 months from now. Because the market may have changed.

What I do know is that if I first spend a few months designing the ultimate way of doing something, then some time implementing, my customer cannot make any progress (testing it, demoing it to his customer, making revenue, finding out what the next step is) during those months, and, more importantly, I'm robbing the entire chain (me, my team, my customers, the company, the customers the company is serving) the opportunity of early failure.

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