Software Is A Craft
I've been writing a lot of code for the past 6 months. I have to admit, it is a welcome change from Word documents and PowerPoint presentations. Java, unlike text and graphics has a clearer definition of correct and finished. But, like text and graphics, the definition of done isn't finite. There is usually a bit more polishing you can do. Another way to factor the code to make it a bit more tidy. And that's something I've been doing a lot of in this 6 month period. Factoring, rearranging, trying to follow the spirit of my blog, add simplicity. It's done when there's nothing left to remove.
I've felt for a long time now that we don't view software engineering correctly. Even that term, "software engineering", illustrates a root cause of the problem. Engineering, in all disciplines, is viewed as the opposite of artistic. I've had these conversations with my "creative-type" friends and it's a stereotype that is common. Yet I view all engineering disciplines as art with constraints. Just like a photographer is bounded by the limits of the lens and the film (or digital sensor), software engineers are constrained by the boundaries of the programming language and the processing power of the target system. But that doesn't make software engineering any less creative or artistic.
Given that though, we teach software like we teach math. Artists are taught not only about the mechanics of their craft but also the art. We stop software engineering after the mechanics. Languages are covered in detail. Code factoring is taught with precision, not as the soft skill that it is. And then we enter the workforce. If we're lucky, we run into some mentors that help us learn our craft. If we're not, we bang out code to project deadlines and while that gives us experience, it doesn't give us skill.
Getting a chance to focus on writing software for the past few months, gave me a chance to understand this reality. I do not make clay pottery but I have friends that do. And what they relate is a feel that you develop for the clay. You come to know when the clay is the right consistency. How much pressure to apply to achieve the desired thickness. And this can only be learned by doing. This is the way software is for me. There's a feeling when the software is coming together well. It isn't something that can be expressed in precise terms, codified into a set of steps. It's an emotional response to the components falling into place cleanly. In other words, it's art.
I thought about how I learned to write software. I was fortunate enough to be exposed to some very good software engineers. They guided me early in my career. Helped me understand the difference between okay, good, and great software. In other words, I spent time as a journeyman. Given problems to solve, code to write, and usable feedback on how I could make my software better. Of course I also learned a lot the hard way. Ideas that seemed good at the time, only to discover they had a serious shortcoming. And of course, I rarely settle on a solution to a problem until I'm completely satisfied with it. We all see the same problem repeatedly through our career and I take that as an opportunity to continue to adjust and refine the solution until I know it is solved as cleanly as possible.
And of course, that is what an artist does. Express oneself in a way that provides satisfaction. Refine the expression until it is succinct and yet powerful. This is what software should be. Concise solutions to business problems that can illicit a positive emotional response from others in your trade. If you don't have emotional responses to software, perhaps this isn't your craft. For that is the only way you can move past just creating code to crafting code.
Technorati Tags: architecture, careers, engineering, java, programming, software, to_read, toread

Exactly. I could not agree more. The more complex the problem the more software become art. At one end of the spectrum, implementation of simple algorithms is mechanics. At the other end, large scale architecture is a great deal creative artistry.
Posted by: Dave M. | Tuesday, March 25, 2008 at 04:08 PM
Very interesting post, Dan. I've been coding a bit this year for the first time since my teens, and although I doubt I'll ever be great at it I have come to appreciate that coding is both art and science. It's easy to forget (or to never recognize) that fact as a product manager without visibility in the code or the process.
Posted by: Kenny Pate | Wednesday, March 26, 2008 at 01:01 PM
Exactly. I also try to explain to people that writing software and designing software models / systems is a kind of art. Unfortunately for most people outside our domain writing software is some kind of nerdy maths. A friend tried to explain what she thinks I do: "you're putting formulas in the pc which it takes to compute the results you want." (...) The universities and other schools teaching IT should add some more creative and "thinking" topics to their courses. I was happy to study "International Media And Computing" where I got the chance to cover both the technical and the arty stuff.
Posted by: Bastian | Thursday, March 27, 2008 at 02:26 PM
Is there a difference in the US as to UK? Engineering is more seen as 'the art of the possible' here, as opposed to science (at least by engineers and scientists). Most engineering is soft, certainly my experience coming as a software engineer from a family of structural and civil engineers is that it's the human factors which dominate engineering.
Posted by: Pete Kirkham | Saturday, March 29, 2008 at 03:57 AM
I also feel that there is a strong element of craft to software - more so in the object-oriented realm than in procedural programming because of the greater level of abstractions possible.
I am old enough to remember a time when computer science degrees were fairly rare, so we had people in the industry that had a variety of different backgrounds. Most of the best programmers weren't engineers or mathematicians, they were music majors. I was talking with one such music major/assembler programmer and his comment was, "Both music and programming is the abstract manipulation of symbols according to prescribed rules".
For me, when I listen to many of the old-school jazz artists, like Oscar Peterson, it feels like we are doing the same thing. Good OO design is dealing at a level of abstraction that hints at the possibility of some possible concrete instantiations. When Oscar plays the piano, he hints at a melody that we get to compose in our own minds.
Posted by: Gary Murphy | Saturday, April 05, 2008 at 07:53 AM