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

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?”

An initial point - the source code is the blueprint. The functioning of the source code is the building. Customers don't pay for code, they pay for functionality.

The distinction missing here is the relative ages of the two professions under consideration. Software engineering, as a profession, is no more than 60 years old (and I'm being generous). Architure, as a profession, is at least 6000 years old. That's a factor of 100. Instead of 3 generations, we're talking 300 generations. This means that, barring really weird concepts, every building under consideration has already been built before. You can point to a building that the customer can go touch which has the characteristics being discussed AND the architect can go look at the blueprints of said building. While there are hundreds upon hundreds of application requests on codelance (and the like) saying "I want to build something that looks just like XYZ", no-one can go look at the blueprint for Word or Windows or eHarmony in order to learn from it.

The only place this kind of information exchange exists is in the OSS world. That, and that alone, is why OSS is so important. It makes coding into something approaching architecture.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

The distinction missing here is the relative ages of the two professions under consideration.

That's one distinction. Another distinction is that software is a virtual product, not even patterns of electricity. If there's a manufacturing step at all, it's running the software through the compiler.