Thursday, May 6, 2010

Putting the "Pro" in Programming
I think programming is an art. There, I said it. I've come out of my conceited little arrogant and ignorant box. Writing code that works well and is human readable is a form of art. Now before you open your mouth to disagree (or roll your eyes because you don't care), let's agree on a few terms:


the quality, production, expression, or realm, according to aesthetic principles, of what is beautiful, appealing, or of more than ordinary significance.
the class of objects subject to aesthetic criteria; works of art collectively, as paintings, sculptures, or drawings: a museum of art; an art collection.
skill in conducting any human activity: a master at the art of conversation.
Now I do have to admit, that definition is rather inclusive. Under this line of thinking, almost anything can be an art. What I want to emphasize about programming, however, is its shared characteristics with other accepted forms of art such as paintings and music.

In paintings and music, the artist has some theme, some concept in their head that they want to convey to the audience. They want the audience to feel it and in some abstract way, interact with it. They start from scratch and work their way up, step by step, until they have their final product. Painters may brush a large background color onto the canvas, stroke a few outlines for a face, fill it with a natural color, and ultimately converge on a Mona Lisa. Musicians may lay down a rhythmic beat, record a guitar, and overlay that with vocals - all the while refining their melodies and little tweaks such as fades and mutes.

Programming is very similar. The artist here (yes) wants to write software to fill a particular need in his or someone else's life. He knows what he wants the end product to be but hasn't filled in all of the gaps yet. He must first carefully plan the approach he wants to take to solve his problems. He starts by perhaps writing a main method that contains some variables and executes some debug code. He may then create some classes and divert the program flow into a state machine or constantly run a loop that checks what it should be doing at any given time. Eventually, he will have all the necessary functions, switches, and flow controls to call his program complete. Like a work of art, it must be aesthetically pleasing. While it's definitely true that many programs are just plain ugly, I can think of quite a few examples of fluid and natural interfaces that make using that program ten times more enjoyable.

And while speaking on the topic of aesthetics, let's not forget the code itself. There are varying degrees of ugly and I'm sure I've seen a lot of them. But I've also seen good designs through creativity and good language features that turn vomit-on-sights to sparkling, wonderful breaths of fresh air. Let me give a very simple example. In C, you might have to do something like this to check the contents of a list:

Now that's just nasty. It took eight lines of code that all look like they just rolled out of bed - mussed hair, bad breath and all. It looks like garbage, and you probably wrote at least one mistake in it carelessly that you'll either notice before you compile or notice later when your outputs aren't what you expect. Conversely, you can use languages like C# that allow you to use predicates and lambda functions on wrappered lists to do operations much more quickly and easily without sacrificing readability:

 In the same way that some art is more compelling than others, so too is some software more usable and better looking than others. We can't all hit home runs every time, but we shouldn't be afraid of stepping up to the plate. We should be open to new ideas that may save us some time or complexity or frustration. We shouldn't be afraid of rewriting bad code, changing a note at the end of the second verse, or slightly changing the color of the sky to match the palette we chose. It might be painful to correct mistakes, but it's often worth it in the end.

Art or not, writing better code is important because someday, someone will have to look at the code you write and it's always a pain having to clean the monitor screen after someone's head explodes.


Post a Comment