Software, Artistry, and Frustration

In describing my approach to software development, I like to use the term practical artistry.  What does this mean exactly?

Well, the practical part of it is that the class libraries, interfaces, and components have to work the way that they were designed.  They should also be easy to use, easy to understand, easy to integrate with.

The artistry portion of this term is much harder to quantify.  Just what is artistry when used in the context of software development?

Art Tatum offers a very compelling definition:

Art is a method of communication which unifies surface details and form while taking both the intended meaning and aesthetics into account. This requires significant amounts of problem solving. The artist is constantly asking, “How can I best express this idea without ruining the proportions of the work as a whole.”

This ties in with Fred Brooks’ principle of conceptual integrity for it is the artist alone who sees the proportions of his work and the artist alone who shall ensure that the work abides by the guidelines of the orginal design intent.

Another term that I like to use is exemplary craftsmanship.  This concerns the little details that make code aesthetically pleasing, readable, and well crafted.  Many small details affect this quality of code such as consistent naming schemes, using extra keystrokes and not abbreviating non-standard terms, ensuring that spacing is consistent, formatting code in a consistent manner so as to make it more readable, and commenting public APIs.  On a higher level, it concerns the organization of code and the clear separation of domains (not in the Fowler sense, but in a more abstract sense) in a manner that enhances the extensibility and orthogonality of the code.

It’s not just code, it’s any trade.  A panel and house wired by a master electrician will certainly be different than a panel and house wired by an apprentice.  The cabling will be neat, the runs will be well thought out, the circuits will be well labled, the panel will be well organized, little details will have been considered, and the artistry of the finished work is apparent even to laymen.

With this in mind, I consider myself to still be an apprentice; I still seek to learn the trade from a master craftsman and I still seek to hone my skills and develop my artistry so that I may also craft software of a high caliber.  But I work hard to ensure that some sense of practical artistry and exemplary craftsmanship is apparent in everything I do.  From simple tasks like ensuring proper indentation in my source files, selecting the right margins in my documentation, and using the right fonts to more complex design issues like organizing libraries in proper dependency chains, achieving orthogonality in modules, and organizing objects in consistent and well defined fashions (i.e. utilizing design patterns).

Unfortunately, in my short career, my interactions with other developers have left me disappointed on this front for the most part except for three individuals whom I didn’t have nearly enough time to interact with (this is not to say that I haven’t worked with many fine developers, but three stand out as practicing these principles of craftsmanship).  These three were true craftsmen in the sense that the little details mattered to them.  Improving their skills as developers was an important aspect of everyday development.  Writing good code and following well known guidelines and principles meant something.  The naming of every class, of every variable, required at least some passing thought so as to ensure that each construct was congruent and aligned with the whole.

Of course, such discussion of artistry as it applies to software is not just frivolous academia, Maarten Boasson writes in The Artistry of Software Architecture:

Designing software is not very different from designing any other complex structure: Few people are good at it; no single recipe always produces a good product; and the more people involved, the smaller the probability of success.  On the other hand, a design produced by someone who is good at design provides an excellent basis for long, reliable service.

Software engineers consider the artistry of the design not only evaluating aesthetics but also the practical results of such a design such as orthogonality and added extensibility.  Boasson further comments:

In exceptional cases, a good software design is no less valuable than the great masterpieces that have been created throughout our rich history.  Examples of both bad and good designs can be found all around us, in almost every engineering field; practically everyone recognizes a piece of art when they see it.

So I often wonder why it is the case that I encounter and, of much greater concern, find high degrees of tolerance for bad design.  Not just bad design, but bad development practices like inconsistent usage of formatting elements (spacing, newlines, tabs), naming namespaces and classes against well established guidelines and practices, and other details like inconsistent casing.  Leadership just doesn’t seem to care for the most part and it requires the rare and truly inspired individual project manager to understand the long term value of encouraging practical artistry and exemplary craftsmanship.

Bear in mind: it’s not that I approach writing software with any sort of artistry or snobbery in mind…indeed, a good portion of it is the grunt work – simply putting the hammer to the nail, or putting the brush to the canvas, so to speak.  But at the end of the day, there is a personal satsifaction that is achieved from not just writing any code, but writing good code.  There is a satsifaction that comes from recognizing and implementing a superior system design.  Of course, it goes beyond personal satisfaction, good design, as Boasson writes, can provide long term value in the form of extensibility, maintainability, and reusability.

In almost all cases, as the majority of developers are not self motivated to write such code, it takes strong leadership, clear definitions or design guidelines, and enforcement of the policies to ensure that quality software – not just working software, but quality software – is crafted.

To me, it is the little details that go towards creating a better product.  There is certainly a time and place for prototyping and RAD – and certainly, I utilize these techniques all the time, but there is also a time to formalize the lessons learned from such exercises and to create a masterpiece…to write code that you would have no qualms about showing to the world and exposing it to critique.

It is with this in mind that I find myself currently flustered.  Is it just me?  Am I being too uppity about all of this?  It’s hard to say…I am truly conflicted about this as I cannot see how I can work productively and cooperatively in a team with people who do not honor the same sense of craftsmanship and artistry.  I awake and find that someone has scribbled on my canvas in a weak imitation of my style using colors that clash with the existing palette.  Analogously, I open the electrical panel to find that someone has stuffed some low grade wire haphazardly into the panel without any clear labeling.  I cannot help myself but cringe at the thought of integration – yes cringe.  I don’t want to deal with ugly code and yet the leadership doesn’t seem to care one way or the other and I am powerless to affect change (partly because I am a blunt edge and possess no sense of finesse whatsoever in dealing with these situations)…*sigh*

I can only hope that some of my desire to achieve practical artistry in code and design inspires others on my team, otherwise this will be painful to endure.