In 'real' art (painting and sculpture for instance) the execution and the expression are inseparable, in programming you can delineate the one from the other reasonably well.

For instance, a mathematician without any programming skills could sketch out the basis of an algorithm, which could then be implemented by programmers familiar with their particular language.

> Didn't an analysis of the Mona Lisa detect multiple layers of paint, indicating that the artist had retouched many parts of it?

Yes, so ? He didn't get it 'right' or 'satisfactory' the first time and decided to change it.

But there is a reason why artists sign their works and programmers can collaborate, even across vast distances on the same work.

In the end it is all bits.

If Da Vinci had reduced the idea of the La Gioconda to 4 squares and you asked four different painters to create the 4 squares and you'd merge them the painting would probably not be hanging in the Louvre right now.

Even if he had sketched it and sent it off in four pieces as a guide it still wouldn't have worked.

And that process works quite well for software, which indicates to me that the two are fundamentally different.

> For some reason, the plumbing and brickwork in programming isn't viewed the same way by all people.

No doubt.

> Perhaps it's because of the use of low level languages (and by low level, I mean anything less abstract than Ruby or Haskell). I personally find it gratifying to refactor code into something more elegant, and I'm sorry if you don't see it that way.

Refactoring code and optimizations are a step above simply putting layers of stone above each other, effectively you've temporarily switched back to architectural mode.

And I definitely agree with you that that is a gratifying thing to do. But it also indicates to me that I should be more diligent during the design phase because refactoring, no matter how satisfying is an expensive thing to do.