A long time ago, after one stultifying conversation too many, I worked out a definition of "art" that I've stuck with ever since. Art, I maintain, consists of expressing as much as possible within the tightest possible set of constraints.
Look at the history of music and that's what you'll see: people setting up rules, demonstrating how to work within them, and then having others take that form far beyond what they themselves achieved with it. Thus Bach's Art of the Fugue formalizes rules developed by predecessors including Buxtahude and Corelli -and demonstrates the form through an entire cycle. Similarly Hayden invented much of what Mozart formalized and made perfect, while Beethoven built toward others, like Shostakovich, by extending the forms he learned from both and exploding the depth and range that could be expressed within them.
I'm told that much of the histories of painting, sculpture, poetry, ballet, and even photography have the same pattern: someone originates and demonstrates a restrictive form and then someone else uses the restrictions imposed by the form to create something that takes its place at the pinacle of human achievement.
A few years ago Janice Heise did an interview for the Sun Developer network with Richard Gabriel - a guy who thinks software development ought to be treated as an art and taught the way we teach literature: by studying the works of our predecessors.
Here's a big chunk from that interview:
Writing software should be treated as a creative activity. Just think about it -- the software that's interesting to make is software that hasn't been made before. Most other engineering disciplines are about building things that have been built before. People say, "Well, how come we can't build software the way we build bridges?" The answer is that we've been building bridges for thousands of years, and while we can make incremental improvements to bridges, the fact is that every bridge is like some other bridge that's been built. Someone says, "Oh, let's build a bridge across this river. The river is this wide, it's this deep, it's got to carry this load. It's for cars, pedestrians, or trains, so it will be kind of like this one or that one." They can know the category of bridge they're building, so they can zero in on the design pretty quickly. They don't have to reinvent the wheel.But in software, even with something such as Java 2, Enterprise Edition or the Java implementation (or almost any of the APIs we define), we're rolling out -- if not the first -- at most the seventh or eighth version. We've only been building software for 50 years, and almost every time we're creating something new. If you look at software developers and what they produce, if you look at their source code, the programs they make, and the designs that they end up creating, there is real variability. And some people are really good and others are not so good.
So, because you can program well or poorly, and because most of it is creative (in that we don't really know what we're doing when we start out), my view is that we should train developers the way we train creative people like poets and artists. People may say,"Well, that sounds really nuts." But what do people do when they're being trained, for example, to get a Master of Fine Arts in poetry? They study great works of poetry. Do we do that in our software engineering disciplines? No. You don't look at the source code for great pieces of software. Or look at the architecture of great pieces of software. You don't look at their design. You don't study the lives of great software designers. So, you don't study the literature of the thing you're trying to build.
He doesn't say it, but there's a quick bottom line: the best programming, the most elegant and simplest code to get a job done, is written in sparse, simple, rule bound, languages like C, Forth, or APL and never in bloatware like Java and BASIC.
That works for me - and, FYI, his website has some interesting stuff for the intellectually adventurous.