I had a thought this morning, about how code is both logic and creativity combined.  Although I've had the same thought at different times through my life and career as a software developer and game programmer, also as an avid photographer and occasional artist and game designer, I wondered aloud whether a vernacular for conversing about programming and game design would ever exist in the same way it has emerged in the world of art or practical design?

I guess a more fundamental question is, is there a need to speak about programming?  And if so, why model it after the vocabulary of art or design?  Perhaps even starting with a few examples of expression about art would be helpful.

To give some context, clearly, my interests lie at the intersection of creativity and logic and emerges in multiple venues.  I started as a self-taught programmer since age 10.  Although I did attend University of Texas for formal education in Computer Science, self-education is a lifelong affair: no degree plan can make you an expert, only competent raw materials to be turned into one with practice and effort.  Further, unlike most folks in my industry, I have chosen to write code continuously for all 25 years of my career in games--often while running one or more businesses.  All told, 35 straight years of writing software in half a dozen languages.  And to this day, there is very limited agreement on how to talk about it.

Given the visual nature of art, there are whole categories of highly descriptive vocabulary: color, tone, composition, mood or atmosphere, pose, form, subject, style, and so on.  But there are technical categories of vocabulary as well: texture, mark making / brushwork, lighting, viewpoint, media, size, presentation, etc.  The elements of creativity and measurable properties are both present in the way one describes works of art.  Why?  Because they are needed to talk about the work, to give some way to induce understanding based on comparable works.  Someone familiar with the "Water Lillies" series by Monet will understand when you say "Haystacks" is also an impressionistic piece by Monet, as that conveys style in familiar terms.  To a lay person unfamiliar with impressionistic art, this word conveys little, naturally.

Now, imagine you work in an industry where you cannot see the entire work at once.  You see it in small pieces, but in great detail, and only understand the whole after seeing enough of the small pieces that your imagination fits it all together like a giant jigsaw puzzle.  This is how programming on a large project is.  You see a page of code at a time, build a mental model of how it looks to you, then imagine how to change it with small steps until it does what is expected.  But there are relatively few words that can convey understanding to another person without them also performing the same arduous task of reading, a page at a time, and understanding how the system fits together.

True, there have been attempts to create Design Patterns in programming.  I will not go on a lengthy tirade about it, other than to state that they have caused as much harm as good.  Rather than creating a series of names for describing code as a whole, they came up with a litany of obscure, arguably inappropriate and empirically fragile code patterns.  Very unlike a general vocabulary, this is more akin to a biologist publishing a catalog of animals that you might find in an exclusive zoo that can only be found in rare and exotic locations and in unusual circumstances.  Naturally, this is not terribly helpful for talking about software that isn't one of those specific patterns.  (However, this catalog of questionable patterns has often been used by inexperienced but well-meaning engineers to pluck "good ideas" from, as if each was equally appropriate and good, having been blessed by the authors.)

No, what I'm wanting is something with more general value.  Like the way you might describe a great sketch artist who makes her subject with an economy of line, some programmers might make elegant and broad solutions with relatively few keystrokes.  With some artists, the heavy layering of texture and rework tends toward the term an overworked piece, where something was just fundamentally wrong--the subject's pose, the lighting, or the curve of a face--and the more intense development only made the problems worse, often by unskilled hands.  Code can be just as badly muddied through lack of discipline and confused authority.

When discussing modules, there are many aspects that code may (or may not) exhibit and we have words or phrases for: fragility, coupling, strongly isolated through interfaces, inverted dependencies, well-documented, weakly typed, and so forth.  To me, these come across largely as describing only the technical aspects of the way parts of a codebase fit together, but lack any ability to convey the flavor or impression or feeling, good or bad, that a professional might have while appreciating the work in parts or as a whole.

At times, we describe some systems will be described as messy, unfocused, unnecessarily complex, poorly thought out, or frustrating.  Less often we use words like impressive, clean, thoughtful, elegant, beautiful.  While these are more in-line with the kind of conversation one might enthusiastically engage in regarding a piece of art in a museum, the application of commentary about code is infrequent and often guarded.  Why?  Because it is typically seen as a personal statement about the author.  

In much the way we can review a book, we should be able to review a codebase, a module, or a single function, with the same kind of terms that convey both feeling and understanding.  We really haven't developed a coherent vocabulary, nor have we developed a distinction between the individual and the author's product.  If software is someday going to be considered artful, and although I believe it does lie at the intersection of the intellectual pursuit of logic, the creative and tasteful application of organization of thought, we might want to address this.  Somehow.