
Programming is not a craft - gozzoo
http://dannorth.net/2011/01/11/programming-is-not-a-craft/
======
DanielBMarkham
Meta note to authors: if your essay has a big TL;DR at the top of it, I'm
going to read that, and then maybe read the rest. Probably not.

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.

~~~
scott_s
I don't think that's fair. In the academic world we call it an "Abstract." In
the bureaucratic world I've seen it called an "Executive Summary." Putting
your conclusions first is also called a thesis statement: this is what I
intend to demonstrate. I actual prefer it when authors just say that up front,
and aren't coy about their conclusions. Some authors can pull off being coy
about their conclusions, but it takes a level of craft (ha!) that most aren't
able to muster.

~~~
mechanical_fish
Academic papers have abstracts because a very large percentage of their
readership won't read the main article.

(For one thing, the abstract has traditionally been free to read and is
indexed by library tools like PubMed, while the whole paper has traditionally
cost a small fortune and/or required a subscription and/or required a trip to
the library stacks and a very tedious photocopying session. What scholars used
to do _before_ the photocopier I have no idea. Maybe they had that tidy
handwriting because they got a lot of practice.)

(Even in the modern era, abstracts can be useful because scientific papers
have a required format that makes them bulky and hard to skim. But, a hint:
It's often better to skim the first few paragraphs and the last few paragraphs
of a scientific paper than to read the abstract. The first section contains
the references to prior work, which help you put the paper in context and give
you hints about where to look next; the ending has the more-detailed version
of the conclusions, with fun bonus features like attempts to pre-empt the
obvious criticisms, speculation about what the work might _really_ mean,
previews of coming attractions, and sometimes even hints about where the
bodies are buried.)

Meanwhile, bureaucratic memos have Executive Summaries because they serve at
least two audiences. If you delete the executive summary nobody with any
political power will read your memo -- executives read only one sentence at a
time -- and your proposal will die alone. If you delete the body you will lose
all of the ass-covering detailed analysis that you carefully larded it up
with, and six months later someone will accuse you of not thinking your crazy
idea through.

But essays don't have abstracts. It's like telling a story by first spoiling
the ending, or telling a joke by leading with the punchline. If the story
promises to be so boring in the telling that it's not worth following along,
don't tell the whole story.

~~~
scott_s
I see no problem with it if the essay's primary purpose is to relay an
argument for an idea as opposed to entertain the reader (and author). It's
basically a thesis statement.

------
rb2k_
Mixing up and cherry picking the concept of an art and a craft made this a
pretty annoying read for me.

> 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.

~~~
getonit
> A solution that requires the minimum amount of effort/energy/material and
> delivers the expected result

As good a definition of code beauty as I've ever seen... even if not as
popular.

~~~
mattdeboard
Why are comments like getonit's getting downvoted on Hacker News now? I'm
obviously assuming it's dwnvoted because it is appearing in a much 'lighter'
font. But has something I don't understand changed about downvoting? Every
article has several constructive comments at the bottom, seemingly downvoted
for absolutely no reason. It's really ruining the comment threads.

~~~
getonit
Because the Emperor is _not_ naked, dammit, and people like me shouldn't be
encouraged to spread rumors that he is :)

Fear not though - as someone with an entire menagerie of unpopular opinions
about programming, business and life in general, karma as a measure of
agreement with the opinion is more useful to me than as a measure of people's
opinion on the constructiveness of the comment. It's also feeding a
spectacular persecution complex, which comes in handy when I discover I've
been talking rubbish on a subject :)

------
Deestan
> Non-programmers don’t care about the aesthetics of software

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.

~~~
jamaicahest
But once we engage in writing software purely targeted at other programmers,
we're in the tool business and I think any plumber will agree that there can
only be so many companies producing monkeywrenches. And no customer cares if
your monkeywrench is the latest version or 5 years old, or even if it works.
They care about getting their water running, their toilet flushing or their
washing machine washing.

~~~
billybob
"...no customer cares if your monkeywrench is the latest version or 5 years
old, or even if it works."

...aaaand, if you have a crappy monkey wrench, you won't get the pipes tight
enough and something will leak. I don't want to see my plumber tightening
pipes with his hands because even I know that it's not going to work well.

The customer just wants a working piece of software, yes. But great tools -
OS, editor, language, development framework, design patterns, UI principles,
etc - help you to fulfill that requirement. The user doesn't know about them,
but indirectly, they do care.

Example: our company had an internal app written in 100% custom PHP. It had
taken a year to create. The developer left and a new one took over. He rewrote
the whole thing in Rails in a week and quickly started making big
improvements.

(Yes, a lot of the time difference was due to work ethic and talent of the new
programmer, but still, the tools were a factor.)

Did the customer - his boss - care about the tool set? Heck yes, he did!
Getting drastic productivity gains and many more iterations of development
convinced him to care. He's now on board with Rails development and willing to
send developers to RailsConf. He has seen that because results matter, tools
matter.

------
lyudmil
This was painful for me to read. It's an important topic, but the author's
argument isn't even false.

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.

------
raganwald
Consider whether there is a trade-off between software that delivers value, is
aesthetically pleasing to the craftsman, and its cost in time and/or money.
You know, "Value, craft, cost, pick two."

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.

------
asymptotic
Due to the sheer volume of responses to this article the author posted a
rebuttal to many complaints here:

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."

------
agentultra
I work on legacy applcations.

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.

------
dgabriel
Even a non-plumber can appreciate craft. Here is what a bad plumber does (and
tried to charge for it). This is a perfect analogy to a terrible piece of
software:

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

~~~
getonit
Context - In a 5 star hotel, that would be appalling. In a house you've just
bought, that would be crap, but at least it works until you get to the part of
the list where you remedy it. In a toolshed/garage/stable/whatever, that would
be prioritising effort - a good thing.

------
angdis
I don't see much point in the argument over whether or not programming is (or
is not) a craft. In my book, you can imagine yourself as whatever you want as
long as it gets the job done-- "engineer", "artist", "craftsman", "fry-cook",
"architect", whatever works, whatever you what call it.

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.

~~~
tjr
I do not recall seeing any field besides programming that tries so hard to
make analogies of itself to other fields.

It's an art! It's a science! It's engineering! It's craftsmanship! It's
architecture! It's culinary arts where FOR loops are part of an NP-complete
breakfast!

Not to say that such analogies aren't fair or sensible, but I feel like we try
much too hard to defend what we do by putting in terms that other people (or
maybe even we ourselves) can understand. I reckon part of this stems from the
fact that we aren't even agreed on what to call ourselves: I'm a software
engineer! I'm a computer scientist! I'm a programmer! I'm a developer! I'm a
chef of the digital cuisine!...

But then, maybe it's not even a bad thing. The fact that we have such mixed
feelings about what we do is all about suggests that people with different
backgrounds can come to our field, bringing their own perspectives to the
table. People who are well-versed in art can come to the field and develop
software from the perspective of an artist. People who understand engineering
concepts can develop software from the perspective of an engineer.

Perhaps there's a spectrum of different styles of software projects, each of
which can make use of different perspectives and different styles of
development. I've worked on avionics software; this is not very creative
development, but it's very strict, and, in my opinion, perhaps some of the
most true software "engineering". I've worked on web applications, where you
can push out a quick version 1 and then iterate even while the user is using
it. A totally different development style. I've worked on mobile applications
where I can't just push a new version, but it's also nowhere near as serious
as avionics; this might fall somewhere in between avionics development and web
development.

Maybe we need software engineers. And maybe we need programmers. And maybe we
need computer scientists. And maybe we need software architects. And maybe we
need software artists. And maybe these all describe someone who builds
software, but with a different style and approach.

Or maybe it's time for breakfast; I wish I had a box of FOR loops.

------
pasbesoin
Ugh, I don't have the time/focus to wade through all of this. With that
qualification, a few comments:

# 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.).

------
pippy
Everyone programs differently. Every artist paints differently, plays
differently or sculpts differently.

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.

~~~
Argorak
Let me broaden your argument: because everyone does everything a different
than everyone else with different tools - such as artists do - everyone is an
artist.

No, programming is not an art. Painting is also not an art per se, etc. Don't
devalue art by attaching the label to every creative task you do.

------
yzhengyu
Personally, the most important take away point from the software craftsmanship
movement [well, as I see it] is that it gets programmers to feel good about
themselves, take pride in their work, and keep on improving. I am sure for
many who burn nights, calories and eyepower against never-ending deluge of
deadlines from incompetent managers, this is good.

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?

------
tehwalrus
Open source and extendable software makes this argument redundant, surely?

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...)

------
jackfoxy
I know how to do something people will pay me money for. I can wander from
urban center to urban center around the world (today literally or via the
internet), and people will still pay me money to use my knowledge to build
stuff, much like medieval stone masons (who didn’t just cut and lay stones to
build beautiful cathedrals, but utilitarian structures too). Meets my
definition of a craft.

------
evangineer
I really liked this blog response:
[http://thinkingbox.wordpress.com/2011/01/12/craftsmanship-
is...](http://thinkingbox.wordpress.com/2011/01/12/craftsmanship-is-not-art-
and-we-care-like-craftsmen-do/)

How long before the Software Carpentry Manifesto?

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

------
jamaicahest
It's a shame the author never touches on the subject of maintainable code vs.
spaghetti code. Some part of the craftsmanship is to create code which can be
built upon in 6 months by someone else, because you've left for another job.
I'll admit that this is becoming a smaller and smaller part of the definition.

------
pbourke
Since we're dealing with metaphors, we're free to invent whatever we want -
the metaphor should be judged on it's usefulness to ourselves and our fellow
programmers.

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.

------
Lendal
What's the big deal? Why can't it be a trade _and_ a craft?

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.

------
patrickk
_"There’s a really cool word for this phenomenon - when you only become fully
aware of something when it fails - but I can’t recall it right now."_

The better a design, the less you notice it.

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

------
tlear
People often do care about aesthetics of the things they buy, from stone work
to plumbing to woodworking

~~~
anamax
"People often do" usually means "some people do", which implies "some people
don't".

If it's a biz, you want to look at the size of each group and what their
members are willing to pay to "get it their way".

If you're doing something to satisfy your itch, you're a customer. How much
are you paying to get your way?

------
Tycho
Here's my take:

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

------
kahawe
> _Non-programmers don’t care about the aesthetics of software in the same way
> non-plumbers don’t care about the aesthetics of plumbing_

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".

------
getonit
I think of this as avoiding 'premature polishing', much as I try to avoid
premature optimisation. The evils are of a comparable nature, IMHO, even
though I don't seem to be in the majority on that one.

'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.

