Programming is not a craft

If you can really boil down all of that text into 2 sentences, then delete the rest of the text. The entire purpose of essays like this is to take a position that I might not agree with, slowly introduce it to me, then convincingly make the case that I should change my mind. Sticking a big TL;DR at the top just invites me to take issue with your conclusions, and convincing me of your conclusions are the entire purpose of your essay. So folks who agree (and agree a lot) will read your essay all the while muttering to themselves about how right you are. Those that disagree will just blow it off, thereby defeating the entire purpose of writing it.

The "art versus craft" discussion has potential, so I was intrigued enough to skim. I just didn't feel the article was well-formed and engaging enough, however, so I can't recommend it. Sorry.

> Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing

I personally care about the 'aesthetics of plumbing' if I'm able to see them (which I might not be able to).

When we're talking about aesthetics, it means to me that I value the thing because it's a clever solution to a problem. A solution that requires the minimum amount of effort/energy/material and delivers the expected result. I don't really care if somebody designed a lock, a valve , a differential gear, a sorting algorithm or an API.

We can also talk about aesthetics in music or paintings, but those will be subject to the person looking at them and the society that person lives in. Some people think skyscrapers are aesthetic, some people dislike them. While aesthetics in art tend to be more subjective, the engineering solutions are more objective in that regard.

So what? All software isn't built for non-programmer end users. Enormous amounts of software is built for other programmers to extend or use.

In software libraries, for example, aesthetics and craftsmanship are vital. To follow the plumbing metaphor, a plumber cares deeply about the craftsmanship of the pipes and pressure regulators.

The Software Craftsmanship movement does make assertions about the aesthetics of software, but more importantly it links the cleanliness of the design with the quality (read: capabilities) of the software. By saying your client doesn't care about the aesthetics of your software, they only care that it works, and therefore software is not a craft you're committing the fallacy of denying the premise because you're asserting those two things are disjoint and independent. The idea of "software as a craft" assumes the two are inextricably linked.

I'd like to add that people who have seriously thought about our field would know how futile it is to make analogies to different discipline. Software is sort of a meta-engineering discipline, where we try to come up with processes and practices that we could use to produce applications that have completely different domains. I think this makes Computer Science intrinsically self-referential and therefore intrinsically different from any other engineering practice or craft. By using analogies you're demonstrating that you don't know or accept this, which ought to automatically disqualify you from the discussion.

I know I stated a lot of the above more pompously and strongly than warranted. It's hopefully a better read this way and more of a conversation starter than a reflection of my character.

If this tradeoff constrains the development of software, then this essay is important because it implies that to deliver software with value, it is more expensive to do so with craftsmanship. If this tradeoff does not constrain the development of software, the entire essay is irrelevant because you can deliver value at good cost while maintaining any standard of craftsmanship you like.

This much is obvious. What is not obvious from the article is that the author has convincingly defined what craftsmanship is and shown that the tradeoff is in effect. Instead, I read cherry-picked examples that beg their own conclusion. Any number of people can play that game if you don't provide a good definition of craftsmanship that is independent of the tradeoff and the value.

For example, if I define "craftsmanship" as reformatting software that already delivers value to be more readable, we have a definition that is not independent of the tradeoff, because readability for future programmers is a component of value. This reframes the discussion from craftsmanship vs. value into how much value is sufficient. That argument has nothing to do with craftsmanship, you can talk about whether software should work for all browsers or just IE, or how fast it is, it's a product management problem, not a question about the nature of programming. Engineers have the exact same argument about how strong a bridge ought to be.

Or maybe I define "craftsmanship" as spending extra time making value-less changes to code. Again I've dragged value into my definition, and cost as well. This argument now becomes a True Scotsman fallacy. If I say that I'm a Java programmer and that I use patterns as part of my craft, I can also claim that they save me time, so you say this isn't part of my craft because it saves me time. You mean the over-engineering patterns, just the ones that are in there for the sake of having patterns. WTF, we can't argue on that basis, the goalposts keep moving.

On craftsmanship http://dannorth.net/2011/01/15/on-craftsmanship/

His rebuttal is, as the author admits, better edited and more pithy. Some key parts are:

"If I gave the impression that I wanted the cheapest or quickest cobbled-together solution then I certainly didn’t mean to. I want the best value software, something that’s fit for purpose in this specific context, to solve this specific need."

...

"I used the metaphor of negative space to illustrate that the point of programming isn’t the software - it’s the information flow or utility that the software enables. Programming is not fine art."

...

"People want software because they want to solve a problem, not because they like the notion of software. Some software practitioners risk losing sight of that. That’s all."

...

"Some people self-identify as 'rock stars' or 'software' 'craftsmen' in an unfortunate attempt to differentiate themselves from regular jobbing professionals, whom they regard as less talented or valuable than themselves. I don’t have much time for these people."

Big, horrible, poorly designed applications. Applications with their own custom string libraries and XML serializers. With bad plumbing and an eye for "making it work."

12 years later and they have to call me in to help them out. It crashes sporadically. It has memory leaks. It's useable but users want new features and programmers can't add them. There's no documentation anywhere. Most of the code is practically unreadable.

A craftsperson is one who practices a trade or skill. The art of craftsmanship (craftpersonship?) is the method and rigor one employs in their studies. To be a craftsperson with good craftsmanship, one must continually practice their skill and endeavour to become better at it.

If you're not a craftsperson and your philosophy of work is to simply "get 'er done," then you don't care about the quality of the work or your skill as a person performing the work. This kind of person will produce the kind of software I described above. True, the users of this software have been using it for years without caring or even knowing what programming language it's written in -- but they do notice the memory leaks when the application sporadically crashes. They do get frustrated with convoluted "features" that are really work arounds to flaws in the initial design of the program.

The quality of your output as a programmer matters. In the case of producing software, the ends do not justify the means. If you write bad code that works, you have only sold your customer short. In my opinion, they pay you for your skill and trust that you will use the best tools available and write software with a high degree of quality.

To use your analogy, people trust the plumber to provide the quality and skill to do the job and do it properly. Not to hack together the first thing that works.

http://i.imgur.com/BIBOS.jpg

If anything, programming today is beset with workers who just don't care about what they're doing. Perhaps a little bit of the care and attention that a "craftsman" ethos brings would be a good thing. It certainly doesn't hurt.

# Crafts-men (-persons) used to be a mainstay of useful products. There was an aesthetic, but they were also successful because they made the best that was available in a locality.

# A significant portion of "craft" is creation and maintenance of tools. Good craftsmen spent considerable effort acquiring and maintaining the best tools for the job. And many were rather inventive in coming up with their own tools an processes. Some caught on and spread; some never escaped their locality and isolation. Many were replicated independently and frequently.

How much of this sounds like today's software industry? A lot, to me.

Programming is a craft. Anyone who's had a brush with e.g. UML, automated systems, etc., knows it's not a hard science (the underlying mathematics is, but we're talking about "programming", here).

I'd say that craft begets artisans beget art. It's a continuum, not an either/or (XOR, as it were).

P.S. Artists would be lost -- at least, to perpetuity -- without the "craft" of their profession. How to make and choose materials that provide for expression and for durability, for example. Canvases, pigments, binders, instruments, notation, sociological/anthropological (whether formal or otherwise) studies (folk songs, dances, etc.).

Programming is an art. Instead of brushes we have ADTs, instead of paint have the UI. If we use the right strokes in the right places, we end up with a master piece.

If we slap it together to make a deadline, people can tell that. Sloppy UIs with stupid data structure decisions really do make a difference.

Now, expending real energy, effort and time agonizing over whether it is a profession, a trade or a craft? Is arguing over semantics really important? Instead of doing that, I say why not spend that energy helping out your team mates struggling with a particularly hard to trace bug or doing more data analysis for the next round of features?

We write good code (as opposed to quick code) in order to make it re-readable and updatable later; making the logic machines more dynamic and, ultimately, functional to end users?

Equally rock star, ultra-pretty code like rails (or even ruby itself) which writes 9/10 of the program for you is also a massive win for customers who get the benefit of cheaper logic machines (because people only have to write the unique/problem-domain components.)

also, I agree with DanielBMarkham, putting a TLDR at the top means I don't read the whole post (which was definitely TL...)

How long before the Software Carpentry Manifesto?

Bonus link if you want a laugh: http://www.artisanalpencilsharpening.com/

Which of the following would you rather be? Which would you rather work with?

- ninja - craftsperson - rock star - artist - resource

Pick your poison. Craftsperson works for me.

Problem is, if you don't have the craft, then you're not gonna get the end result. Just don't shove the craft down the customer's throat. That stuff is for colleagues. The customer wants to hear a different but not necessarily competing message.

The better a design, the less you notice it.

At least, that's what sprung to mind for me.

Art starts where (prior) science/utility/craft/trade stops giving you answers.

Take an abstract painting. The only functional requirements are that it covers a canvas which you can hang on a wall, and that it will interest viewers. Beyond those things there are really no 'answers' or 'directions,' so the 'artistic territory' begins immediately. If you've ever tried to make an abstract painting, you'll know that even when you don't know what the hell you're painting, you still know there are bits you like and bits you don't. The art is in exploring this uncharted territory to create a whole work that somehow pleases, albeit due to little understood principles ('why is this splotch of green more appealing than that blob of red?').

Take another piece of visual art, say a portrait - it's supposed to capture the likeness of the person, as well as fit on a canvas etc., so there's a bit further to travel before you're in pure artistic territory. If it's a piece of graphic design, an architectural sketch, most of the journey is just applying techniques to capture the functional requirements.

In a discipline like maths or engineering, most people, most of the time, are working well within the established techniques, to solve problems that have been solved countless times before. You need to go a long way to reach the cutting edge, where mathematics can become an art.[1]

Programming, however, sits somewhere in between. While it's nothing like abstract art, as we do have vast sums of established knowledge, plus best practices, standard techniques, etc., I'd wager that most programming projects have a very large quotient of 'the unknown' (as evidenced by the failure and lateness rate of IT projects). Therefore programming is in large part an art - there are often no well trodden routes to success, but the great programmers always seem to get there. They tame the unknown, but not in a way that can easily be transmitted to other workers/programmers.

When you see a piece of embroidery, it's artistic in the sense that we don't know exactly why it is appealing, but the person who 'crafted' it was probably not exercising any great artistic expression, just repeating an old design. Just because something's functional requirement is to be aesthtically pleasing, doesn't mean it's a 'craft' which is intrinsically different from disciplines which lack that particular functional requirement. We need to rethink what we mean by art and non-art. In paintings or music, the jump-off point is almost immediate: you have few functional requirements, and few relatively rules to guarantee results. From there onwards it's down to insight/ability on a fleeting, individual basis. With other disciplines, you have many functional requirements and many rules/procedures that let you meet those requirements if followed diligently. Sometimes aesthetic appeal is one of the requirements, sometimes not. But there comes a point once again where only individual insight/ability can bring further progress. Our only choice is to rely on talented people.

Have you ever seen the film, 'A River Runs Through It?' It's about two estranged brothers who are reunited in adulthood, and they think back to years before when their father would take them fishing. Their father said the most important thing for a man to have was 'art.' He didn't mean owning pictures, or painting them, he meant whatever vocatoin/profession/trade you choose, you need to make an 'art' of it. The narrator/protagonist's brother (played by Brad Pitt) was a failed person in some respects, but he had developed an incredible technique/knack for fishing that nobody else understood. Thus, he 'had art.'

So anyway, programming does not usually involve aesthetic appeal as a functional requirement, but it is sometimes an 'art.' I would conclude therefore that we need to listen to the advice of our greatest artists... but you can never replace the art with a formula.

[1] of course, we very often operate on the edge of our own abilities, but until we've reached a frontier where no one else has gone, our 'art' wont deserve any audience

At least you can witness how non-programmers put up with the most absurd and downright horrible software shenanigans on a daily basis as long as the thing somehow helps them, or rather does not completely hinder them, in getting something done. And it is remarkable how quick some of them can pick up on it and how high their levels of tolerance really are.

If anything, this really shows and explains why so many absolutely abysmal "solutions" and "quick hacks" can very well keep on running forever, so to speak, until the day it comes to a screeching halt and some poor, completely unsuspecting fella is called in to "have a quick look at it".

'Clean lines' is my mantra. Whether it be done through a remote API, a database queue or a multitude of classes, loose coupling and sensible, strict and adaptable communication between clearly separated units is my number one priority. Everything else has, at the very least, the danger of encouraging the traces of the architecture astronaut within me... and he's enemies number one, two and three :)

The units themselves can be as good or as thrown-together as circumstances demand, but the separation/communication being of a professional standard is set in stone.