Thank you, that's indeed the distinction I'm trying to make. Good article.

If I sell you a PC in parts, it's still a PC, you just have to assemble it.

If you're a statistician and I give you 10,000 peoples' poll results in separate files, you have the product, you just have to compile the statistics. Then the sociologist or politician or whoever interprets the statistics.

At all stages it's a product, but it's not finished until the end user can us ie.

A design is not an unfinished product. It's a plan for how to take raw materials and turn them into an unfinished product, with the idea that a finished product can then be made from those.

The design is sometimes not even concerned with turning the unfinished product into the finished product, as that's sometimes a well-defined production process.

I think the basic terms proposed are somewhat flawed. I believe very few people think of programming, bricklaying, carpentry or masonry as "crafts". People think of gluing flowers together or carving soap as crafts. I think people think of them more as "trades". Traditionally, you have the aristocracy/idle rich/statesmen, then the top working rich/merchants/company owners, then the professionals like physicians/teachers/attorneys/engineers, then the tradesmen like carpenters/masons/brewers/clockmakers/surveyors (and in modern times farmers), then the skilled laborers such as the apprentices to the above and the blacksmiths/weavers/tailors/bakers/butchers/soapmakers/herders, then the unskilled laborers who do brute force work.

There is a use of "craft" which fits, but I don't think that's the most popular connotation of that word. To think of programming from someone else's design as a trade and to think of designing software as architecture or engineering I think makes sense.

An unfinished product is still a product. If I sell you a PC in parts, it's still a PC, you just have to assemble it.

Then you have a different definition of product from myself, and that's probably a source of confusion :-)

For me being finished is part of what a product is. If not how far back can we go? Where is the dividing line between raw material and "unfinished product"?

The design is sometimes not even concerned with turning the unfinished product into the finished product, as that's sometimes a well-defined production process.

But surely the design of the product must specify its final state, even if it doesn't specify the exact process used to reach that state? In which case (with my definition of product) I would say that the source code would meet your definition of design.

I think the basic terms proposed are somewhat flawed

Amen to that.

Personally I have a loathing for comparisons between software development and engineering / architecture / crafts / whatever. They're almost always based on misconceptions of how the various professions operate.

I believe very few people think of programming, bricklaying, carpentry or masonry as "crafts".

And I believe that many people do consider them crafts - but that may be influenced by the fact that my father still sits in the chair that my great-grandfather made ;-)

Give my Dad the source code to Word and he won't be happy. Give him a running program and he will be (at least, as happy as anybody can be with a copy of Word ;-) Source code is not a product

That is an old, but fundamentally flawed argument. The fact that the source might need to be compiled into a different language (machine language instructions) to be used as intended doesn't mean the source isn't the product. The source code for the Parrot virtual machine isn't a specification of that virtual machine, it is an implementation of that virtual machine. Knuth's TAOCP volume I *specifies* a MIX machine without implementing one. It could be implemented in Perl, C, or even in hardware. And if I write MIX machine code that implements SomeApp, that machine code is my source code for SomeApp. The fact that the SomeApp's source code happens to be directly executable on a physical MIX machine, but is ultimately translated down to a completely different machine code when run on my Perl or C based virtual MIX machines, doesn't make that source code a final product in the first case, and just a specification or design document in the second case.