Shift the metaphor over a step or two
IMHO it's misguided to declare that "real software" is the cheap/free bits that the compiler spits out ("manufactures") and that the source code is the design. It creates a false analogy with physical manufacturing and leads to conclusions that are I think unjustified.

Instead, the level *before* coding -- the unloved but important task of writing a spec, considering possibilities, evaluating tradeoffs. *That's* design. A well written spec should remove the ambiguities from the coding process.

Want an analogy to physical industry? The spec is the blueprint and the spec writer is the architect. The construction worker/coder takes the blueprint/spec and makes the building/program.

Does this demean "coding"? No. The spec writer needs to be a talented programmer to make a realistic, robust spec. But the tough decisions should be made in the spec writing process, not in the code writing process.

As the software creation industry (call it want you want: programming/software engineering/whatever) matures, there must be a necessary distinction between the coder/construction worker and the designer/architect. The coder/construction worker still needs plenty of skills -- the welding, tile cutting, and circuit-breaker installing equivalents in the world of source code. But those skills are different than the skills required to create a great spec.

Shift the metaphor over a step or two
"there must be a necessary distinction between the coder/construction worker and the designer/architect"

That's depressing. I like aspects of both roles and I wouldn't want to be stuck full time as either.

Shift the metaphor over a step or two
Sorry, rigor is often depressing. I often feel the same way. And there are plenty of projects where you can do both. If you're a reasonably handy architect or a carpenter who's read up on architecture, you can probably design *and* build an add on to your house or a new garage. But not an apartment building.

So w/r/t small projects with less stringent robustness needs than widely-distributed or business/mission/buzzword-critical software, you can work both sides of the fence, too.

Important difference
On an assembly line, each worker makes a specialized work, and doesn't need to know or understand what the other workers do. At the contrary, in a team of programmers, it's critically important that everyone understands at least roughly the common design and communicate precisely.

Gardening
Andy Hunt & Dave Thomas (the Pragmatic Programmers) have used the Gardening analogy for software development. http://www.artima.com/intv/garden.html

That works for me on most of the stuff I'm doing, but whether there's a single metaphor which covers all of the art/craft/science/fun/passtime of software work I don't know...

hordes of replaceable labor
"the people on the other side of this debate seem to prefer the cheap hordes of replaceable labor as the important point of the image"

People on both sides of the debate seem to prefer replaceable labor. XP has the notion of "TruckFactor" or "TruckNumber". It is the measure of how many people can get hit by a truck without the project falling apart. Why they chose such a morbid example is beyond me. Perhaps they think it's funny. Imagine telling a team of developers that they are bound to succeed even if John, Ann, and Sally get hit by a truck. The only problem, they are told, is that the project would suffer if "Diatonic" were hit by a truck. Therefore, the team is encouraged to figure out a way to make sure everything would go just as well if by chance "Diatonic" found himself on the wrong end of the TruckFactor.

Although I can see the benefit of having backups to disasters, I value people as individuals, not as just so many fodder for traffic accidents as XP proponents do. It feels good to know that your individual and UNIQUE talents contributed to a project, and that if you were not there it wouldn't have been the same. The same goes for others as well. We enjoy seeing others excel and part of teamwork is DEPENDING on others unique skills.

So while you may regret the characterization of developers as assembly line workers, I regret developers who insist we must act like assembly line workers, be treated like assembly line workers, and work in environments that look like assembly lines. (rows of people very close together).

Taylor Cowan

Scale of Evolution
Take a step back and look at the larger picture. The way the construction is done today did not happen over night. It has evolved over time. Would you not say then, that all previous constructs are Prototypes to today's version of construction?

How does this relate to Programming? When a specification is made, it is a varyingly detailed description of a problem and a planned solution to that problem. The more times you solve a particular problem, the better you get at writing the specification. Since construction has been around so long, there is a well defined set of problems and their solutions.

Writing code is a lot like building a prototype, except that code can be reclaimed into the next version(generation) much easier then someone could convert a building into another building.

Becuase of the fast development cycle of software, it is easy to see the changes. But, how many people can see the changes in construction without first studying many decades of it?

In closing, software development is like every other human endeavor before it, but becuase it is possible for ideas and results to be produced so quickly, it is evolving noticably and in ways that can't all be seen together.