You're not going to build a single thing from, or onto, my “nice one-bedroom cottage” unless you show up with a blueprint or an equivalent drawing. I also expect a firm estimate:   if it costs you more money than you thought it would, that's your problem. If it doesn't conform exactly to what we agreed to, I know the judge will give me a summary-judgment. (Judges have done that for me in the past... in my favor.)

When people know that I know what they want, for a well-defined piece of work that we have all agreed-to in advance, then there has never been a problem getting paid. Or, getting more referrals than we could use.

If the customer “doesn't want anymore” what you contracted with him or her to build ... then you certainly were not ready to start work. Either they threw away their money, or you threw away your time, or both. That's not “being in business” ... that's starvation. The average lifespan for the usual computer-services one-man-band is about two-and-a-half years, so I'm told. We must have eaten a bunch of ’em for lunch and didn't know it. And oh, the stories we heard about “corporate I.S. departments!”

One crucial aspect of our profitability was that the “task orders” that were an integral part of our contract system were small and well-defined. The first one or several were for specifications-only. Often the first task was to (be paid to...) work out and to discover what to do. (The core idea for this came from Hermann Holz's various books on Consulting Contracts, still in-print. “Priceless.”)

Say, were you working in Phoenix, Arizona in the mid-to-late 90's? If so, I owe you dinner and several strong drinks. I made a lot of money off of you... ;-)

Say, were you working in Phoenix, Arizona in the mid-to-late 90's?

I worked in construction in the late '90s, which I find terribly amusing.

You're not going to build a single thing from, or onto, my “nice one-bedroom cottage” unless you show up with a blueprint or an equivalent drawing.

In the world of software, we call this blueprint the source code.

If it doesn't conform exactly to what we agreed to...

... then you probably changed your mind, like customers do, both in construction and in software.

If you made so much money with those nearly-mythical customers who know exactly what they want to the point where you can specify it in legally-binding terms before you write a single line of code, good for you. You're the first person I've ever talked to who's ever had one customer like that anywhere.

C'mon, my anonymous friend, don't give me that... :-D You were in construction, so you know darn well that the source-code is the building itself, not the blueprint. In computer software, the source-code is “the final work-product.”

I'm quite sure that you never walked onto a job-site where the paper-work had not been done first, even if you yourself never saw it. (If you didn't have somebody running ahead of you making damm-sure that the i's were dotted and the t's were crossed, well, you learned that lesson “only once but quick!”) If the customer changed his or her mind, then negotiations occurred, and the results of those negotiations were written down and signed or at-least initialed. Likewise, if a “valid change-order” came to bear upon the project ... which, as you say, does happen from time to time, well, there was a change-order, and it served as an explicit and binding modification to your (or your company's) contract. A daily log was kept, and kept up-to-date. Somebody made sure of that.

I'll never forget this little contretemps from the old TV Show, People's Court:

• Judge Wopner:   Do any of you have the faintest idea what it is you two actually “agreed to?”
• Plaintiff and Defendant: I guess not, Your Honor...
Go figure. I rest my case. ;-)

There is safety in that attention-to-process, and I am absolutely convinced that this is also the reason for satisfied customers who bring you new referrals “out of nowhere.” Or, as the case may be, for hunger and busted friendships. Plenty of consultants out there rely upon this thing ... their professional reputation. I don't know why computer programmers, who daily engage in some of the most demanding mental work imaginable, don't pay attention to this kind of discipline.

Anyhow, the bottom line for me is that what applies to other related disciplines does apply to computer-software development. Many of the mistakes and bad-practices that would never be tolerated, say, in the construction trades ... are the subject of glossy books in the computer section. It's baffling to me. “The so-called professors who write those books ... what are they smoking?”