[guy_5676]

Code isn't an "artifact", it's the actual product that you are building and delivering. You can use flowery language and pontificate about the importance of the problem domain if you like, but at the end of the day we are producing a low level sequences of instructions that will be executed by a real world device. There has always been, and likely will always be, value in understanding exactly what you are asking the computer to do

[alexandre_m]

Product != Artifact

Artifacts are snapshots of system knowledge (code, builds, docs, configs, etc.).

The product is the living whole that emerges from these artifacts working together and delivering value.

[guy_5676]

I'm familiar with "artifact" being used to describe the inconsequential and easy to reproduce output of some deterministic process (e.g. build artifact). Even given the terminology you provide here it doesn't change the content of my point above.

When I see someone dismissing the code as a small irrelevant part of the task of writing software, it's like hearing that the low-level design and physical construction of a bridge is an irrelevant side-effect of my desire to cross a body of water. Like, maybe that's true in a philosophical sense, but at the end of the day we are building a real-world bridge that needs to conform to real-world constraints, and every little detail is going to be important. I wouldn't want to cross a bridge built by someone who thinks otherwise.

[enraged_camel]

In most domains, code is not the actual product. Data is. Code is how you record, modify and delete data. But it is ultimately data that has meaning and value.

This is why we have the idiom: “Don’t tell me what the code says—show me the data, and I’ll tell you what the code does.”

[HPsquared]

Code is just one way of representing a specification.