[et_pb_section admin_label=”section”][et_pb_row admin_label=”row”][et_pb_column type=”4_4″][et_pb_text admin_label=”Text”]
Background
So, there is some debate in developer circles about whether programming is an art, a science, or both. Recently, I have heard the word Code Craftsman and even Code Artist used by folks in the blogosphere. On the one hand, there is little argument that written code can be judged and appreciated on the merits of beauty, quality, and clarity. On the other hand, members of your team will not be amused by you finding new and extraordinary ways to manipulate standard syntax just to change it up. I think this is the danger of shackling ones self to analogies; at some point they just break down. Also, if you take yourself as too serious of a Code Craftsman you could end up in a physical confrontation like Michelangelo and Pietro Torrigiano.
When dealing with code, the tangible qualities of beauty, quality, and clarity are what we use to choose, for example, one free JavaScript library over another. But, is this so different from what we do when selecting any product? I think comparing code to art is an analogy that may have overstayed it’s welcome. Instead, why can’t we just talk about being good programmers who are professional and have forethought when writing code. I understand the attraction to analogies, they feel good. The problem is, they also limit our scope of thought in unforseen ways. I don’t think beauty alone qualifies something as art and I will detail some distinct differences between code and music to demonstrate my point.
Getting Creative
Clearly, the Python example below is not art. In fact, I suspect, any coder reading this post is cringing at the way I tested the editor variable. Your probably saying things like, “well those aren’t logically equal” or “that’s a horrible way to test” or “that is fragile and stupid”. But, they produce the exact same results at this very moment on my computer. In computer programming there really is no merit placed in finding creative ways of producing the same results if they are fragile. In music, there is no concept of frail.
print os.environ['EDITOR']
if os.environ['EDITOR']:
print os.environ['EDITOR']
if os.environ['EDITOR'] == "vim":
print "vim"
var = "vim"
if os.environ['EDITOR'] == var:
print os.environ['EDITOR']
Let’s take a similar example with music. Let’s say I am playing a standard 1/4/5 pattern which would commonly be found in a rockabilly song. One, four, and Five, simply designate the first, forth and fifth notes in the major scale are the main notes we will use to construct the song. Now, if you play guitar or piano. Make up something to this rough pattern, but stick to the pattern. Anything you can come up with is fine as long as you adhere to the basic notes. Now, when you get tired of playing the same thing over and over, change it up by adding a fill.
Verse: G, A, C
Chorus: G, C
Verse: G, A, C
Chorus: G, C
Bridge: B, C
Verse: G, A, C
Chorus: G, C
Instead, it is pleasurable to listen to music if sometimes the musician leads in and out of the chorus with different fills. Monotony is broken by using different notes each time the musician plays a fill. Could you imagine how annoyed another programmer would get with me if I used different standards every time I created a variable. Imagine, all CAPS one time, HAlf another, CamelCase another, like modern art for variable names. In computer programming adding fills is just ridiculous, but it would make a good blog title “CodeFills.com”. Again the analogy breaks down because there are no standards when playing a song in my band, there are never written documents or tests to make sure the song passes.
The Danger of Analogy
These techniques of adding interesting entropy are similar in poetry, painting, sculpting, writing prose, dance, drawing and other arts. This is not true while coding. Now, I know you have the urge to say, “yeah but….”. Don’t! Stop making the analogy to music, or art in general, it is not useful when trying to uncover good coding practices. I will quote a paper written by Dykstra to assist in my point:
By developing a keen ear for unwanted analogies one can detect a lot of medieval thinking today
People make analogies to assist in their thought process, but I don’t think that they realize there is a trade off in analogy as opposed to qualitative description. Analogy by it’s self will take us back to medieval times. Instead, let’s just describe what makes a good programmer qualitatively using the properties that they actually have. Furthermore, I think it is dangerous for programmers to think of themselves as artists. I believe that it gives them the impression that they have creative license when they are bored. This leads to code that is fragile, untested, and difficult to read.
Conclusion
If people are so fond of these analogies, then I must take it to it’s logical conclusion. I am obliged to make a distinction between someone who composes music, and someone who can faithfully perform it on an instrument. There is creativity and art in both, but they are very different practices. Generally, pop and jazz band musicians are a bit of both composer and performer, I do not believe this is true with the programmer analogy.
I think that as a programmer, if you must be a Code Craftsman or artist, try to produce faithful renditions of the business specifications. Faithful rendition is the highest form of respect to the trade and the most productive way to code. When taking the analogy back to music, it fails because there is no productive way to play music. Likewise, there is no merit in putting in fills between bars when coding. So, let’s enjoy both, but as things that are distinctly different.
Links
- http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF
- http://www.cuddletech.com/blog/pivot/entry.php?id=1150
- http://en.wikipedia.org/wiki/Pietro_Torrigiano
- http://www.codesqueeze.com/software-engineer-vs-code-artist/
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
Interesting post. It does seem that nary a thought about a programming concept is eschewed anywhere in the blogosphere without dipping into a pool of often poorly chosen analogies. Books and presentations, etc. share the same fate.
I think its a natural extension of the programming process. Generally, its about creating software paradigms that model some real world problem. The temptation to continue that practice in casual conversation about technical matters is clearly powerful.
I still have to consider programming an art, however. Not in the sense of painting or drawing or writing music or sculpting. Rather it is an art in the sense that a surgeon practices an art. The word holds meaning in that not all that is expected of the programmer(or the surgeon) can be summed up in concrete terms, but rather expectations vary by situation. A certain amount of judgement and creativity is required from time to time to deal with issues that offer no simple solution.
Many vocational endeavors subscribe to this meaning of the word art; it is not new. In fact, state of the art as a phrase refers to many industries. The problem you identify, I think, arises from this somewhat ambiguous term being ill-understood. While programming has an artistic side, that side is still driven(ideally) by practical considerations.
In fairness, other artistic endeavors of a more classical variety are beholden to the form follows function principle as well. Architecture must satisfy function. Just as one would not want a random choice of case styles or indentation practices in source, one would also prefer doors to be reliably sized and at appropriate places to be utilized gainfully. Still, there ARE things in a discipline like architecture that become part of the design PURELY because they are pleasing. This is not the case with programming.
Great post. Good to see EC getting some love.
So, I must say, even in architecture, I think you may be able to go a bit further. If I wrote code that looked like the Peter B Lewis, School of Management building people wouldn’t work with me anymore:
Mike’s right on about this. “Art” is an equivocal term. We use it to signify fine art, such as music, poetry, literature, sculpture, etc; but we also use it to signify the practice found in crafts or trades like carpentry and HVAC. An art in the latter sense will be something like a body of executable precepts followed for the production of some external result and, consequently, have a set of standard operating procedures with varying degrees of flexibility (the less flexible, the less novelty one can introduce in the product without running the risk of violating the precepts, and vice versa). Despite the fact that architecture has more flexibility than programming, it seems unproblematic to identify both as an art.
I’m curious, though, in what sense would programming be a science?
Well, I do not agree that it seems unproblematic, this article is about application to being a better programmer not an argument on the meaning of the words. I see programmers fighting everyday about how each of them is “doing it wrong.” Over my career, I have observed hundreds of such arguments. Applying the correct algorithms has a right/wrong based on the current technology. Algorithms are discovered and proved mathematically. At any given time, there is a body of knowledge from which to retrieve and apply the best algorithm of the day to a specific problem. This “state of the art” is slowly accepted in a fairly standard scientific manner. The algorithms are essentially hypothesis of what is correct way to do something in a computer and they change over time.
Also, I would make a distinction between programming and coding. Programming is thought process that can be done regardless of language, while coding is specific process in each specific language. My argument isn’t to stop using the word art, it is to stop comparing our selves to musicians and painters, it’s just not productive and causes so many of the “you are doing it wrong” arguments. Check out Dykstra’s paper for some of the argument, he is a smarter man than me: http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF
http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF
I introduced my comparison simply to shed light on the behavioral patterns underlying the problem. I think that the word ‘art’ is problematic in the sense that the article describes, but because the difference in meaning that I have identified is not understood by the speaker. This postulate should be testable during the course of these debates Scott identifies.
I do think you can go much further in architecture than in code. I did not mean to imply that you cannot. There is NO fine art element to programming, but there clearly is such a piece to architecture. That is why I mention that there are things that are pure form and no function, for which there is no allegory in the world of programming. To invent one is to, in reality, create the problem that is identified in this article.
Agreed, this is when people start adding fills!
Right, the debate over whether programming is a science vs. an art isn’t merely semantic and I didn’t mean to imply that it is. When we label/categorize an object or activity, it reveals something about the paradigm through which we conceptualize that object or activity. If your point that thinking about programing as an art – in the sense of fine art (art*1, for short) – is counter-productive (and you make this point well in the post), then perhaps these debates are better served by using art in the sense of craft (art*2) to conceptualize programming. I believe Mike has done this with the analogy of the surgeon, which seems to me (a non-programmer w/ some exposure to programming but not privy to the nuances of these debates) far more helpful in providing the programmer some insight into how he or she should conceive of the relation between creative license and the standards of his or her field than does any comparison with art1. In fact, I’d say this bit in the conclusion – “if you must be an artist, try to produce faithful renditions of the business specifications. Faithful rendition is the highest form of respect to the trade and the most productive way to code” – prescribes a conceptualization of programming according to an art2 paradigm.
The coding-programming distinction is helpful. It reminds me of the artistic2 and scientific modes of logic. On the one hand, the logician will engage in general consideration of various argument forms and common patterns that appear within content, In this mode one explores the nature of formal systems and devises general strategies for constructing good arguments & criticizing bad arguments. It’s basically puzzle-solving at a level once (sometimes twice) removed from systems like arithmetic or ordinary language. On the other hand, the general strategies hit upon in the scientific mode are specified when put to use in actually constructing or criticizing arguments. Perhaps something similar can be said about the coding-programming distinction – i.e. that a scientific and an artistic2 mode can be recognized in the discipline.