Programming is not a craft

TL;DR

Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.

Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their information in the right place or their hot water to work. (Although it’s fair to say they appreciate decent boiler controls.)

Motivation for software craftsmanship

It would be great if programming were a proper profession, but it isn’t. A profession has a structured model for advancing through levels of skill and ability, be it studying for a law degree and articles (working for a legal practise) or the years of undergraduate and medical training a doctor undertakes before specialising. The latter has clearly-delineated ranks, from junior doctor, via a brutal regime of 80-hour weeks, to consutant.

Conversely there is no minimum entry requirement for programming. Some people naturally have a flair for it (two of the best programmers I know never went to college), some teach themselves out of books, others just tinker until they get something working. A programmer’s skill and ability is only as good as their personal reputation: there isn’t an accepted, transferable ranking like there is in a “proper” profession.

To illustrate how low the bar can be, the mission statement of Visual Basic (whether explicit or not) was to democratize programming. Anyone who could drag and drop controls around and understand a modicum of technical stuff could throw together a solution to a problem with relatively little effort. Wizards and other utilities enable power users to create sophisticated spreadsheets in Excel with no practical programming knowledge. Language guru Erik Meijer has spent the last few years talking about democratizing the cloud, i.e. making it as easy to string together online services and utility computing as VB made it to string together other applications. In other words, there are people actively working to lower the already low barrier to entry for programmers. (These are Microsoft-specific examples, but then Microsoft has done more than most to dumb down programming, or make it accessible to the masses, depending on your point of view.)

The IT industry is relatively young – only a couple of generations old in fact. (As an experiment, go and find out how many of your coworkers have a parent who worked in IT. See?) It is also something of a gold mine. Compared to a lot of industries it is relatively well paid indoor work with no heavy lifting, and remember the thing about no minimum entry requirement? This means entire economies have grown up looking at IT as a numbers game: if you throw enough bodies at a problem you should be able to make it go away, and if you can get bodies for cheap enough (yet still relatively well paid compared to the alternatives) then you can throw a lot of bodies at a problem.

I spoke to someone once who told me he was currently engaged in a public sector project to provide online tax credits for builders. As a builder you would have an account online where you would log in and buy tax credits that were offset against your end-of-year tax bill. In other words, it was a site that had user accounts and a (third party) card payment facility, and not much else. This project had 400 programmers working for three years. That’s more than a person-millennium of effort. For a web app! That I’m paying some consortium for out of my tax money. But that’s a rant for another day.

So from a purely demographics perspective we can see that the vast majority of people in the IT industry are there because a) it’s a well paid alternative to other white collar office work or even manual labour, and b) there is no incentive to make it anything other than a commodity numbers game.

Then there are the others. The minority of people who genuinely love programming and choose to excel at it. They understand software development is a skill, in fact a whole portfolio of skills: understanding and modelling a problem domain, understanding programming languages, libraries, paradigms and idioms, choosing which to apply in a given situation, learning and understanding algorithms, mastering the “path to production” (build, deployment, release), monitoring and availability, process automation, Lean theories of supply, production and product development, utility and cloud computing, concurrency and parallelism, I could go on. Those guys want a way to differentiate themselves. The oft-quoted figures of tenfold increase in productivity of expert versus novice programmers are wrong by orders of magnitude in my experience. A really great programmer (and I’ve been lucky enough to work with a handful over the years) can out-perform a doing-it-for-the-money programmer by orders of literally hundreds, delivering in hours or days what would take an average developer weeks or months.

How are those guys supposed to differentiate themselves? And how can they help others in the industry who have a real love and appreciation for the software they write? We need some sort of apprenticeship model, and a way to identify masters, both to apprentices and other masters. That sounds like the sort of model that craftsmen use. And it also appeals to the average alpha geek’s romantic streak, possibly incorporating a system of secret signs and handshakes.

The thing is, at one level software can be described by the utility it provides. It doesn’t matter how ugly it is under the hood as long as it delivers the goods. A programmer can show beautiful software to another programmer, but that’s where the appreciation stops for software per se.

Seeing the negative space

My wife is an artist, and one of the things she studies is negative space. This is the space between the obvious shapes or objects in a picture, as opposed to the objects themselves. An understanding of negative space is critical to being able to faithfully render a composition. As the model sits sideways on, notice the curved triangle bounded by the upper and lower arm and the side of the body. See how the space between the front of the face and the window frame in the background is nearly rectangular and quite narrow, and see how the outline of the nose creates a dent in the left-hand side of the rectangle. Look at the chin, actually the space below the chin, to observe the angle between the bottom of the jawline and the front of the neck. And through the window, notice the colour of the sky in the space between the winter tree branches. It’s different from the grey-white cloud above the trees. All of these shapes and colours – the space between the obvious stuff, the negative space – these are the shapes that determine how faithfully you represent the image on a canvas. But mostly you don’t notice them – especially in a good painting.

So what does this have to do with software? Well it seems to me the most succesful programmers I’ve encountered don’t craft software; they write software in order to move information around, in order to get something done. Information is the real deal – the software just defines the space that it moves around in. For those programmers, success is about getting information from point A where it’s currently languishing to point B where it’s going to actually be useful, as quickly and effectively as they can. Success in a UI is about rendering or capturing exactly the information that will be useful – no less and certainly no more – in a succinct, obvious way. The software is incidental, a detail, hidden away in the wings, and it is ultimately entirely disposable.

Why programming is not a craft

With a craft, the product has intrinsic beauty in its own right. A cathedral is really a big hut for people to meet in and worship. Make it from stone by all means, so it lasts longer than a wooden hut, but why all the fancy decorative stuff? Of course it is there to engender a sense of majesty and wonder, and cause us to engage the part of ourselves that appreciates beauty and magnificence, so we enter the cathedral reverently and humbled, ready to worship. What makes it a craft is the work above and beyond its basic utility to give it intrinsic, aesthetic beauty.

If I use the same stone to build a traffic bridge over a railway line, I care about its utility and structural effectiveness. If it’s a good, simple bridge I won’t even notice it’s there! We don’t notice most of the engineering that goes into the roads we travel on or the railways we use until something goes wrong! (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.)

There is a difference between the mindset of a master stonemason sculpting the expression on the face of a gargoyle and someone using the commodity blocks that make up a multi-storey car park. In the latter case the last thing I want is someone’s “personality” causing some of the blocks to be different sizes and no longer interchangeable, never mind the added expense of having someone manually hew the stone rather than using machine tools. In the former the stonemason’s attitude is indulgent. He is putting his signature (and his ego, and his reputation) into this magnificent representation of Hell’s best. If you just wanted an oil-pouring spout you could get one from a DIY store.

Software practitioners – especially, ironically, the good ones – often lose sight of this. They fall in love with the software itself and start thinking of themselves as craftsmen of software.

The easiest qualification in the world

So here’s my concern with the idea of Software Craftsmanship. It’s at risk of letting programmers’ egos run riot. And when that happens… well, the last time they went really nuts we got Web Services, before that J2EE. They convinced the British government that they wanted an uber-database to store Everything Ever About Everyone. You see where I’m going?

When I looked at the Software Craftsmanship Manifesto, something inside me died. (Something else inside me burst out laughing and told the other thing to stop taking itself so seriously, so we’re all better now.) Apart from being, well, bland, it is just so self-evidently an oxymoron. If its message is that we need to think of ourselves as software craftsmen and that this is somehow special, then what a spectacularly easy bandwagon it is to jump on.

Do I need to demonstrate any kind of skill? No. Any specific credentials? No. Any kind of experience working in the field? Nope (and as the Pragmatic Programmers are happy to remind you, ten years experience is very different from one year repeated ten times). In fact, all I have to do to associate myself with Software Craftsmanship movement is to fill in my name on the website. Woohoo! I’m now associated with the Manifesto of Software Craftsmanship! Is no-one else seeing the irony here?

The (original) travelling salesmen problem

Back in the day – while the West was busy being Medieval – Japanese warlords used to hire bands of mercenaries called Samurai to, well basically beat up other bands of Samurai. Your life expectancy as a Samurai warrior was usually pretty low, and dropped dramatically if you came off your horse. In such times the martial art of jiu jitsu was born. The premise with jiu jitsu is that you have come off your horse in battle: you are unarmed, outnumbered and your opponents have both a height and weapons advantage over you. You’re pretty much stuffed unless you can pull some cool moves out of the bag.

As Samurai moved around, hiring themselves out to different warlords, they would want to join the local martial arts school to continue their training. Now you can imagine, if you learn jiu jitsu in one dojo up to a certain standard (we’ll call it a black belt) and then turn up at another school, it’s pretty tricky to get any kind of calibration without involving some life-threatening fighting with the new kid. And without calibrating, you can’t know whether someone is any good.

Ever resourceful, the jiu jitsu schools developed a sort of dance, called the nage-ne-kata, comprising five groups of three techniques. For each technique you both execute the technique and have it done to you, to demonstrate not only your fighting skills but your falling and rolling abilities. All senior students would learn the nage-ne-kata, and if they went to a new school, the sensei would ask them to demonstrate it for them. It is still taught today in some ju jitsu schools.

You can tell a lot about someone’s jiu jitsu from their nage-ne-kata: how they stand, how they hold their stance, how they move, how graceful they are, how well they understand balance, how well they respect their uki (the partner), how well they roll and fall (and how quickly they get up!), whether they favour one side over the other, their spatial awareness. Just from one little dance.

Let’s be craftsmen then

So, back to the plot, I’m reassured by the kinds of people I see involved in the Sofware Craftsmanship movement, the likes of Kevlin Henney, Bob Martin, Corey Haines, Glenn Vanderburg. These are pragmatic, sensible, down-to-earth and above all genuinely humble people. My concern is that the glamour is overtaking the intent, as evidenced by the sheer number of people wishing to align themselves with the Software Craftsmanship movement.

I would love to see someone rewrite the Software Craftsmanship Manifesto in terms of getting results and delighting customers. I don’t want “steadily adding value,” I want “amazing their customers every day!” Software craftsmen should be egoless, humble, with a focus on the outcome rather than the code or the process. I’d like a call to arms to stop navel-gazing and treat programming as the skilled trade that it is.

No-one wants your steenking software – they want the capabilities it gives them, and they want those yesterday. (I’ll specifically exclude the User Experience folks. Theirs is genuinely a world of aesthetics and human understanding. They, to use a bricklaying term, do the face work – the fancy stuff people actually see.)

Maybe there should be a Software Craftsmanship Council, that confers membership in a collegiate yet transparent way, in just the kind of elitist model that desperately upsets the folks who have systematically dumbed down the education system in the UK (but that’s another rant for another day). You only get to join if those already there believe you will be a credit to the notion of Software Craftsmanship, just like Ph.D. viva boards do today.

A truly skilled programming team can deliver amazing business results in insanely short amounts of time. Let’s go after some of that! I want your experience. I want your knowledge. I want you to show me “the simplicity the other side of complexity,” to quote Oliver Wendell Holmes. It takes a real expert – a real craftsman – to see the elegant simplicity buried away inside the mess we call enterprise software, for instance, and tease it out.

Calling programming a trade takes nothing away from the desire for professionalism, experience and expertise. In the same way I want an expert electrician wiring up my house rather than a cowboy, I want an expert programmer enabling my business. What I don’t want, however, is a prima donna plumber who insists on talking about the elegance, beauty or art of plumbing, or who insists that I appreciate the aesthetic beauty of his joinery, or will “only work with other rock star plumbers, who only practise copper-driven plumbing.” The best software should be understated and unobtrusive (as, maybe, should be the best programmers). I don’t want to hear the clanking of information as it rattles from one poorly-implemented system to another, through ill-conceived interfaces.

So what now?

While I was formulating this article I made a few comments on Twitter about it and I received some interesting responses. One person suggested a programmer is a craftsman not unlike a silversmith. I would argue that the value of silver or gold jewellery is intrinsic to the jewellery. I don’t use the item for anything other than for others to admire its beauty (and by association my significant-yet-understated wealth and taste).

If we’re going to use gold or silverwork as an analogy it would be in something like a speaker cable, where the properties of gold contacts improve the quality of the sound. In this case, however, I want the gold connector to be identical to a cheaper one. If the cable manufacturer wants to demonstrate their aesthetic abilities, I’ll be a lot happier if they do it by making the cable look fancy than by messing around with the shape of the connector!

If you’ve read this far, then thank you. Now here’s what I want you to do. I do think there should be a Software Craftsmanship Manifesto, but not the thing that’s currently out there. I think it should be a call-to-arms, feisty, opinionated, brash and everything that a good manifesto should be (I’m channelling Kevlin Henney here). I also think there should be a way for passionate, skilled programmers to differentiate themselves from the mainstream commodity bodies, and also to recognise one another, and demonstrate their value to potential employers. What could that be, and how could we make it work?

As a buyer of software solutions, wouldn’t you want to know your systems were being built by master craftsmen rather than day jobbers? You’re paying for this and you deserve some kind of reassurance. Let’s figure out how to provide it.

247 comments

  1. Hi Dan, this is a very good post, because of a few key moments:

    “Well it seems to me the most succesful programmers I’ve encountered don’t craft software; they write software in order to move information around, in order to get something done. Information is the real deal – the software just defines the space that it moves around in.”

    — I totally agree here: the users of the software, and the purchasers / sponsors have a reason for wanting it. That reason is the results it enables them to have. It is not the intrinsic nature of it being “software”.

    “I would love to see someone rewrite the Software Craftsmanship Manifesto in terms of getting results and delighting customers. I don’t want “steadily adding value,” I want “amazing their customers every day!” Software craftsmen should be egoless, humble, with a focus on the outcome rather than the code or the process.”

    — For me, while I certainly enjoy coding and learning about great techniques, patterns, etc, there is nothing that compares to knowing I’ve delivered what is *Actually Needed* to achieve the goal of someone using it. In my experience, this becomes most real when we, as developers / architects / whatevers actually observe real users in unscripted situations. If we can develop the empathy and compassion necessary to channel our own energies to delivering the products and services that do the job and delight them, GREAT!

    It’s never any consolation to me to hear a developer pontificate about how “beautiful” or elegant his or her solution is if it ends up being slow, annoying, or just plain buggy when the user attempts to utilize it in the product!

    “What I don’t want, however, is a prima donna plumber who insists on talking about the elegance, beauty or art of plumbing, or who insists that I appreciate the aesthetic beauty of his joinery, or will “only work with other rock star plumbers, who only practise copper-driven plumbing.” The best software should be understated and unobtrusive (as, maybe, should be the best programmers). I don’t want to hear the clanking of information as it rattles from one poorly-implemented system to another, through ill-conceived interfaces.”

    — F*ck copper-driven plumbing. The “clanking” of information comes in the form of slow, bulky, glitchy, broken results. I think some developers “get high” on writing code, seriously, and that becomes an addication. These personalities seldom take a step back and look at the larger picture and ask “What does the user / sponsor really need here?”

    What’s worse is when developers, or project leaders, won’t go the “Extra mile” to work with their sponsors to help them understand what’s really needed from the business-perspective.

    On an agile project I recently worked on, our sponsor, after months of development, said she would have dramatically altered the early Road Map to focus on very core business-related features, had she known things would not progress as fast as she expected. I don’t feel like that is her failure, but our failure. Well, maybe it’s a combination. But, when a team is trying to help their customers deliver value, I think it’s critical that the team itself understand where value comes from and, ultimately, where their client’s own customers place value.

    All that being said…I do believe that the vast majority of programmers believe they are doing the best they can and in the interest of the project. It does take strong leadership to coach and guide an entire team toward shared goals that benefit the business and users most importantly.

  2. Hi Dan:) thanks for this post – the title really made me laugh as the slogan on my personal website is “I’m not a craftsman, rather an explorer”, which I came up with while trying to define what is it I like in the Programmer professions and what I don’t :)

  3. Hi Dan, I loved this article. I’ve been in the industry for a long time and I’ve seen all sorts come and go. I’ve worked with some great people and meet some of prima donnas. The sort that spend all day waxing on about how software should be written and how everyone else is doing it wrong. And I’ve usually found that the software they produce is so wrapped up in showing how great they are that it’s practically unusable to the rest of us. For me, a persons worth as a developer is simply about how happy the users of their software are, and how simply they can produce great experiences. No rewriting the wheel to show off, over-engineering to satisfy some pet design methodology or using “K00l” technologies without any gain – just simple code that works.

  4. David W · ·

    Hi Dan,

    I wholeheartly agree that Craftsmanship shouldn’t lead to a bunch of prima-donnas but truth be told I don’t think that it will. Prima-donnas will always be prima-donnas at the end of the day. My own experiences are that of working for one of the UK’s most recognisable dot coms. A small number of people who were not natural software developers got the site up and running from nothing in a really short period of time and were rightly praised for doing so. They no longer do software development and I am part of the team that picked from where they left off. The code-base is horrible and we struggle to maintain it. The scalability is dreadful and piles and piles of cash are thrown at servers that are starting to creep. One of the biggest mistakes made is huge levels of copy-paste programming.

    The business guys see the original group as angels that put the brand out there but can’t understand the problems that we have. There was no respect to craftsmanship and over the long haul the business can’t understand why everything has become so slow to turn around. An example would be that the business gets frustrated because you forgot to update terms and conditions (copy and pasted into code behind?!) on one of 400+ pages?!

    My point is that signing code or writing beautiful code isn’t about showing off how good you are – it is about leaving something clean for the next person. The goal should be consideration for fellow professionals. When you spoke about plumbing it sounded like the best analogy. Not only would a great plumber fix your problem, he should do so in a way that the next plumber that comes along will understand. Whilst I agree that you wouldn’t want a plumber using a hand-crafted ornate piece of piping, you also wouldn’t want him using a piece of a hose that is lying around to fix your problem. Neither would be considered qualified by http://www.guildmc.com/

    I hope that SC doesn’t become the next ‘Badge’ with an industry queuing up to make money out of handing out pretty Software Craftsman pin-badges to stick on your CV and flatter egos. Rather the craft should be based around code that reflects the right attitude to the craft.

  5. Mr. North — While I commend your sense of authority and swagger I’ve a contrary view.

    You might be under-estimating the power of culture when you think you are a craftsman.  The reality is no one cares if it’s craft or it isn’t, its about creating products people love. Those gentlemen / women that you mentioned out-producing the paid thugs…. those coders care about about being unique, being artists, being craftsmen.  No one argues about how many lines of code they write and how fast their algorithms (and the ones that do often don’t give two shits about the customer experience or what they provide to consumers).  I think its rare you get talented coders that don’t want to feel some speed in their hair and have some flair in their step.

    Code as craft is nothing more than a culture hack by business to solve a human problem — genius is art and art is genius it’s been that way since Europe rebounded from the plague and emerged from the dark ages. They did it on the tails of the creatives, not on sound operational management. The fact is is everyone else in your “proper” professions is just drawing a bunch of really pleasing straight lines that no one will ever care about and certainly won’t click on a link to see :).  You want great products then you need to give people something exciting and beautiful to believe in.  If that wasn’t true the British would still run America, No one would use facebook, foursquare would tank because google maps had all the answers, and something like twitter …. not even a remote possibility.

    Most importantly, if viewing code as craft wasn’t proving somewhat effective, there would be no story here to write.

    There’s my counter move, thank you Friday night #angryfriday

  6. [...] Quoted from http://dannorth.net/2011/01/11/programming-is-not-a-craft/ [...]

  7. John :
    I love this bit:
    “I want an expert programmer enabling my business. What I don’t want, however, is a prima donna plumber who insists on talking about the elegance, beauty or art of plumbing, or who insists that I appreciate the aesthetic beauty of his joinery, or will “only work with other rock star plumbers, who only practise copper-driven plumbing.”
    Brilliant. Totally brilliant

    I get what you mean. But I do think you want a plumber who cares about his work so you dont have to call him back every day to fix another problem…

    So you actually need a plumber who is in love with his work (craft). Makes beautiful solutions you benefit from. And yes, he should not over-engineer. I’d rather hear a plumber talk about beauty of his work than a plumber who does not care at all.

  8. [...] blog posts recently.  The first is Dan North’s blog on the Software Craftsmanship movement at http://dannorth.net/2011/01/11/programming-is-not-a-craft/ and the second is by Gojko Adzic at [...]

  9. [...] been reading Dan North’s post on programming as a craft, and Adewale Oshineye’s response. I also don’t view programming as a craft. I believe [...]

  10. I believe coming up with innovate solutions to problems really is an art form. It takes a whole lot of creativity and outside the box thinking to come up with quick elegant solutions to a problem. In my experience what I would consider actually good programers write useful code. Code that does something useful as in doesn’t waste the computers, other programers, and the stakeholders time or resources in accomplishing the task.

    Something you failed to mention in your article is the whole concept of “programing for fun”. In my off time from work I program node.js stuff in Coffeescript. Not a whole lot of what I write is actually useful or solves any real world problems, but it sure is fun.

  11. [...] Where did the leadership go?  It was great to see Liz talk about BDD not being about tools and Dan North pushing back on Craftsmanship. [...]

  12. Chocholac Petr · ·

    this might do the trick … not surprised it comes from Germany :-)

    http://www.engineering-card.de/index.php?id=2490&L=1

  13. ipipeline_dev · ·

    Software need craftmanship, There are many ways to get things done on a smalll scale, but the well crafted software(or well architected software) is the one that is easy to expand and easy to maitain. I whole heartly endorse BDD, behavior is the spirit of software, I also endorse software craftmanship, slapping thing together will create huge problem down the road, and only real programmer is willing to purse the road of software craftmanship.

  14. [...] They are not interested in paying extra for work that does not address that goal. As Dan North noted: There is a difference between the mindset of a master stonemason sculpting the expression on the [...]

  15. 1. When you go hiking, mountain climbing, boating, fishing, cross country skiing, canoeing, or take part in any other outdoor activity, do you have a survival kit in case you get lost, injured, or separated from the group?

  16. [...] 这不仅反映出了澳大利亚一个较普遍的问题,该问题在其他国家也同样存在。举例来说,Dan North的博客中发表了一篇名为编程并非工艺的文章,此文章引发了众读者热烈的讨论。North认为编程不适合被作为一个职业。在他看来,软件工程师的门槛有些过于偏低。 [...]

  17. [...] Neighbors, Jade Meskill and Clayton Lengel-Zigich discuss Dan North‘s article “Programming is not a Craft“. PREVIOUS: Springboard Series Project NEXT: SCRUMCast Special Episode: 2011 Predications [...]

  18. [...] Discussion It all started with a post by Dan North that was critical of the movement. Members risked being elitist, indulging in navel-gazing, and [...]

  19. [...] a topic that has seen a bit of back and forth in the blog world after Dan North unleashed Programming is Not a Craft. You can find some of the responses at the bottom of this post by Martin [...]

  20. [...] Dan North: Programming Is Not A Craft – Kritischer Blogartikel (englisch) zu Software Craftsmanship von Dan North, dem Erfinder von BDD (Behaviour Driven Design) [...]

Follow

Get every new post delivered to your Inbox.

Join 463 other followers

%d bloggers like this: