Software Development: Artistry or CraftsmanshipBy Paul Ballard
Are you a software artist? Does your code represent the sublime thinking of a technical genius? Should your innovative use of pointers be hung on a wall in a museum? Have your peers ever reviewed your latest check-in and wept loudly and openly (in a good way)? Most likely the answer to these questions is no, and that is actually a very good thing.
Can you tell these two chairs apart? Barring some slight variation in material color they are for all intents and purposes equivalent. One of these however is a priceless piece of art created by Mies van de Rohe from a collection held at the Museum of Modern Art in New York City. The other is a mass produced reproduction on sale at Amazon.com for about $350.00. One of these chairs was created by an artist, and the other THOUSANDS were created by craftsmen. Which one would you rather buy? And what the heck does this have to do with software?
Software Art versus Software Craft
There are several key differentiation points between software developed as art and software developed as craft.
- Software art is meant to be seen, software craft is meant to be used. I, like hundreds of other developers, have written technical articles or samples that have been published in various magazines or websites. In that code, I tended to fret and consider every nuance from variable names to keeping my loops properly optimized. I knew that the source code itself would be viewed, critiqued, and possibly ridiculed by the general public and so I did everything I could to make sure that it looked professional and could be used as a foundation for other developers work. However, if you took all of that code I wrote and dropped it into a compiler, it seldom just worked. In fact, there are often pieces omitted for space or because it would obscure the details I was trying to highlight. It wasn’t meant to inspire, not be used itself.
- Artists tend to be individuals, craftsmen often work in teams. The expression of any idea as art, be it software or painting, is generally an individual activity. While an artist may seek out structured criticism from an agent or editor, they generally go back into their environment alone. Craftsman on the other hand work in teams, dividing the labor based on skillsets or resources. Each craftsman contributes to the end result but is not solely responsible for it. A software artist usually works alone, at least on the first inspirational PoC. Software craftsman work in teams, agile or otherwise, and build software as part of a larger organization.
- Art is expensive, craft is… well, less expensive. A software artist may spend hours agonizing over some key new innovation or feat of technical prowess, but this time costs money. If not directly in salary, it certainly costs the developer their time. Software craftsman build their code based on timelines and production levels. They can’t afford to lose several days of productivity based solely on the desire to be creative. This in turn reduces costs for the organization and/or end user making that priceless app something we can afford to buy on Amazon.
- Works of art are by their nature individual, where crafts are reproducible. While Mies van de Rohe may have created a beautiful (and uncomfortable) chair, he didn’t produce 10 of them. And he certainly didn’t produce hundreds or thousands. Because he was only creating two chairs for the King and Queen of Spain, he did not have to worry about producing two more the next month or improving and upgrading the chair after it was sold. Craftsmen on the other hand produce, and reproduce, the same products on a consistent basis. In software the key to sustaining quality and productivity is a consistent, reproducible process.
Most developers who actively work on their skills strive to produce innovative code or apps that are at least artful if not actual works of art. But how much time do we spend honing the craft of software development? Should we optimize loops or focus on unit tests? Should I write code that expresses my personal sense of style or should it be indistinguishable from the rest of my team? While each situation may call for a different solution, how do you decide on art or craft?
About the Author
Paul Ballard is a Chief Architect specializing in large scale distributed system development and enterprise software processes. Paul has more than twenty years of development experience including being a former Microsoft MVP, a speaker at technical conferences such as Microsoft Tech-Ed and VSLive, and a published author. Prior to working on the Windows platform, he built software using a vast array of technologies including Java, Unix, C, and even OS/2.