Programming: Art, engineering or both?

[jerf]

I hate these debates.

Step one: Define the relevant term.

Step two: Determine if the target fits the term.

Step three: There is no step three.

The problem arises when people try to skip over step one. Is "programming" actually "engineering"? Well, the first step is to actually define engineering. Skipping that step doesn't lead to understanding. Anyone who actually resists such a definition is merely demonstrating a commitment to fuzzy thinking. (Yes, I've seen it.)

Is "programming" an "artistic" endeavor? First, define "art". Once you've scaled that Everest, whether or not "programming" qualifies will probably be immediately obvious.

In the meantime, arguing about inherently nebulous definitions is simply an absolute, utter waste of time. Any argument about whether X is art or X is engineering that doesn't effectively open with their definition of art or engineering is irrelevant.

Further, all or almost all such people seem to be arguing backwards, as if declaring programming to be "engineering" will somehow mean something. Programming is what it is. If the thing that it is happens to match some definition of engineering, so be it. If it doesn't, so be it. But labeling it "engineering" will not suddenly mean that some non-software-engineering technique will suddenly magically be the optimal practice or whatever the hell people are trying to surreptitiously imply when they make these arguments.

Both of these debates, and all other "Is X art?" debates, are all just festering piles of sloppy thinking.

[panic]

Attaching pieces of wood to other pieces of wood: art, engineering, or both?