Programming is not a craft

http://dannorth.net/2011/01/11/programming-is-not-a-craft/

by gozzoo • 15 years ago

33 39 15 years ago

rb2k_• 15 years ago

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.

getonit4• 15 years ago

> 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• 15 years ago

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.

pmccool• 15 years ago

> 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 myself think the problem is precisely the opposite: people do care about the aesthetics of plumbing, and of programming. They just care about it in ways that have nothing do to with how well it works. We, as consumers, care far too much about "pretty" and far too little about "effective".

Well-crafted anything doesn't necessarily stand out, IME. It just works. This is an admirable trait, but it can't seem to compete with "beautiful". It's a shame that making things that work well is somehow less admirable that making things that look nice.

getonit4• 15 years ago

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.

DanielBMarkham• 15 years ago

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_s2• 15 years ago

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.

tjr2• 15 years ago

I find the attitude conveyed by "TL;DR" to be different than that conveyed by "Abstract" or "Summary". While in essence a "TL;DR" section is indeed a summary, using that term suggests to me that someone (in this case the author) questioned the value of reading the entire text.

mechanical_fish• 15 years ago

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.

lyudmil2• 15 years ago

My experience was even worse. After reading the TL;DR I thought the author's point was vacuous. In order to comment on it responsibly I had to read the whole article, knowing that very likely it wasn't going anywhere. I think if you're worried about how long a post is enough to add a TL;DR, you should probably edit it down.

Deestan• 15 years ago

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

jamaicahest2• 15 years ago

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.

stonemetal• 15 years ago

They care about getting their water running, their toilet flushing or their washing machine washing. What part of doing that job quickly and robustly doesn't speak to the quality of the job done? The client may not be down there looking at the plumbing every day but the reliability, and ease of future repair is directly related to the quality of the job done and is something the client most certainly cares about.

billybob• 15 years ago

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

angdis• 15 years ago

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.

tjr2• 15 years ago

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.

kahawe• 15 years ago

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

asymptotic• 15 years ago

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

dgabriel• 15 years ago

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

getonit4• 15 years ago

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.

tlear• 15 years ago

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

anamax• 15 years ago

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

Lendal• 15 years ago

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.

tehwalrus• 15 years ago

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

jamaicahest2• 15 years ago

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.

raganwald• 15 years ago

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.

pippy• 15 years ago

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• 15 years ago

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.

lyudmil2• 15 years ago

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.

yzhengyu• 15 years ago

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?

pbourke• 15 years ago

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.

patrickk• 15 years ago

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

jackfoxy• 15 years ago

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.

agentultra• 15 years ago

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.

pasbesoin• 15 years ago

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

Tycho• 15 years ago

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

evangineer• 15 years ago

I really liked this blog response: http://thinkingbox.wordpress.com/2011/01/12/craftsmanship-is...

How long before the Software Carpentry Manifesto?

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

Programming is not a craft

Related Stories