Programming is not a craft


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


  1. […] cezargBr  dan north post a controversial thoughts about software craftsmanship movement….. edbott  So, in the name of "openness," when will Google publish details of its search […]

  2. […] have been trying to keep up with the discussion around Dan North’s post but being on holiday makes it difficult. Luckily the slowness to respond allows me to not write […]

  3. we need to move from craft to engineering, to bring discipline, to create a real profession.

  4. It is enjoyable to read this thread of comments by people much more articulate and smarter than me. Hopefully I won’t spoil it for the others by adding my vague opinion…

    A hundred or so years ago, people had very similar situation with almost the same deep questions. The topics back then were: the artistic value, crafts (or trade if you wish) and industrialization. That led to ‘Arts and crafts’ movements, which look very goofy today, and later on to a solid, synthetic multidisciplinary approach – Design. I mean, The Real Design; an universal humanistic discipline with methodologies, measurements, analyses, etc. Maybe it’s time we come up with a new paradigm that integrates all the efforts when creating software, too? Of course, that might not solve much in future. It will still be shaky and dynamic, but that’s where the fun is!

    Being a designer myself, I am saddened to see so many ‘things’ that label themselves ‘designed’ without substance, or to realize how much time and effort the ‘designers’ put into ‘navel gazing’ (another, a less decent word comes to mind). The humanistic ideals of design are almost lost in self-satisfaction. A design/product/software that is a fruit of a self-centered effort without a proper scope of real needs is very often a pain to use. So, in the end, I am not using it. I don’t even like to see it. Still, I must let it be. The time and effort wasted on such projects is a very unfortunate fact, and this fact alone might annoy me, but give it time and the society will push it aside or accept it.

    The Name or the Ritual/Method we use when we create is important, but might not matter too much. None of those are ultimately right or correct, and they are here only to be changed. The effects of our creation, on the other hand matter a lot. And everything we do can be checked against the basic ‘trinity’ of concepts. The truth, the goodness, the beauty, A.K.A. the logic, ethics, aesthetics A.K.A. shin, zen, bi.

    These three permeate everything we do. So, there *is* beauty in an exceptionally well engineered bridge or software; there is logic in a painting masterpiece; there is goodness in crafts, etc. Focusing on just either one will result in a less than good result.

    As I said, I am not too smart, but even for me these three (logic, ethics, aesthetics) usually provide a solid reality check.

  5. […] avoid getting drawn into the arguments around all the blog posts going back and forth about whether Software Craftsmanship is a craft, and whether or not […]

  6. […] North says that programming is a trade, and not a craft.  I agree with him that it’s a trade, like plumbing and wiring.  I’ve already […]

  7. […] avoid getting drawn into the arguments around all the blog posts going back and forth about whether Software Craftsmanship is a craft, and whether or not […]

  8. Daniel Skinner · ·

    WE Must Crack Down on false people pretending to be real programmers; HARD!
    Just because someone can remember some things, throw some jargon around and startle some non-IT people around them, doesn’t make them worthy of even being related to IT, let alone being a programmer (software developer/engineer).

    As far as I’m concerned (and I now sound like a broken record to myself ;] ) if you don’t understand and can’t program in C / C++ (don’t have to know absolutely everything about it), then you are NOT a software developer or engineer!
    If all you can work with is JavaScript, VB, Python, ASP.NET, you are certainly not a programmer. You are more like some guy who learnt a few tricks and learnt how to utilise an IDE and make heavy use of Google!

    Agile software development, scripting, software craftmanship manifesto, etc – are ALL rubbish!! Anyone solely associated to these things for example are not real IT professionals. Sure you might impress your grandma and teach a few friends a trick or two, but in reality you are living a lie, claiming to be someone you’re not!

    I’m not saying these people can’t become true IT experts, but seriously, earn it and most importantly, prove it!

    I CAN’T WAIT until the days of Quantum Computers. We’ll see if these jokers still have a place then (without VB, .NET, wizards, Google, Intelisence, etc).

    In short… If you don’t understand how a base2 number system works and you can’t write code in C/C++ at least to some degree (not needed to be an absoulte gun) then you are not a software developer (engineer), whatever you want to call yourself. They are the same anyway. If fact developer is better, because realistically an engineer is a train driver whom can also fix up the consist as a whole. So with any other profession, engineer is damn lose term.
    Lastly, if you are ‘in IT now’ and you don’t know what a base2 number system is, smack yourself and quit while you’re ahead, because you are a truely unprofessional I rather consult my fish for IT advise than you!

    1. C/C++ is for whimps! Real programmers use punch cards.

      1. LOL!

    2. Hi Daniel. I appreciate your passion, but I think you’re at risk of a kind of affinity bias. I know many people who came up through different routes – like Smalltalk, various flavours of Lisp or specialized languages like APL and its derivatives – whom I would consider craftsmen and whose programming smarts I couldn’t hope to match.

      I agree you need deep technical skills – in whatever your chosen technologies (by which I mean the languages, libraries, idioms and patterns) – as well as extensive experience, and that you can’t fake that experience by learning a few tricks. However I don’t think it’s useful to mandate what those technologies should or shouldn’t be.

      1. Daniel Skinner · ·

        Hi Dan,

        Yeah you are right, there is other languages and technologies out there that fit into the category I was suggesting.
        Take my previous post as more of an example rather.


  9. […] gone from Dan North’s post, to Gil Zilberfeld’s to Michael Feather’s to Jason Gorman’s.  It would […]

  10. […] the programming internet has been about the craftsmanship label,  “Michael Feathers”, “Dan North”,  “Gil Zilberfeld”, “Jason Gorman” and finally “Rob Martin”, have blogged […]

  11. Daniel Skinner · ·

    Hahaha, punch cards.
    I see your angle, but there would be nothing done if we had to all use punch cards with today’s expectations on developing software.

  12. Ah, but what if they were *Enterprise* punch cards?

  13. The nage-ne-kata bit got me a bit intrigued. Isn’t that something that may also work in assessing one’s ability in making software? It obviously doesn’t tell the whole story, especially what to expect from a person when confronted with new and unusual situations, but it may tell you a lot about his/her mastering of the tools and the manual process from idea to software. There is kata examples at codingdojo. I certainly miss some that touch on modeling business related domains but it’s a start. Isn’t that sth to expect from people? I do not dare to say certification, but maybe you can ask to “perform 1-2 katas of your choice” as part of e.g. a job interview…

  14. This whole topic seems to be based in our confusion between knowledge and fluency . Willem Larsen (who has a proposed session at Agile 2011) and Evan Gardner have talk about this in context of their language fluency technique “Where Are Your Keys?” (check out:

    As Willem poetically puts it:

    Valuing knowledge over fluency has created an epidemic of normalized incompetency in the modern world.

    When we can articulate software [craft/development/engineering/whatever] in terms of fluency characteristics, I believe it more adequately articulates most concerns.

  15. I’m proud of having been aware of the SCM since its early days and having NOT signed it despite having some respect for those who wrote it. I’m a tradesman not a craftsman and I’m proud of writing software that works while delivering it on time and to budget. The manifesto and I agree on absolutely nothing.

    Well-crafted software is nice. Working software is imperative.
    A good looking bridge is no better at crossing rivers than an ugly one. And lets face it, the point of a bridge is getting from A to B reliably, not beautifully.

    Steadily adding value is nice. Responding to change is imperative.
    Inability to respond to change is like being a plumber who left his adjustable wrench at home whilst steadily adding value is like being the plumber who’s been under the damn bath for the last 3 hours and still hasn’t replaced the washer seal.

    A community of professionals is nice but you can’t have one without individuals and interactions.
    The developer community has as much appeal to it’s business customers as a Vegas dentists convention has to the gamblers at the slot machines.

    Productive partnerships are nice but businesses do not function without customers.
    Saying partnerships are more valuable than collaboration is like saying marriage produces better babies than sex.

  16. I’m a long time Dan Fan, but I have to disagree. I’ve built two houses, and worked with plenty of tradesmen to do it. What distinguishes a trade from a craft, to me, is that in a trade there’s a Right Way to do it, whether proscribed by a building code or local tradition (e.g. screws vs nails here in the US).

    To a tradesman, every job is different, because every wall is different, but each job consists of the same basic parts combined over and over and over again. You won’t find many carpenters who spend their time tinkering with better ways to put up drywall, or machines to help them put up drywall faster, or comparison-testing different fastener types. A tradesman gets better with practice, but it’s an improvement of manual skill, not of the trade technique itself. Creating Exchange user accounts is a trade; tech support often resembles a trade. But programming?

    And if you think every bridge doesn’t have its own character, its own style, and even its own gargoyles, you haven’t spent much time around roadgeeks or major construction projects. Come to the East Coast of the U.S. and I’ll take you on a hundred-year span of spans.

  17. […] flurry of tweets about Software Craftsmanship, reignited as a hot topic by Dan North’s take on the Software Craftsmanship manifesto and a subsequent retort by Ade Oshineye have had me thinking the Software Craftsmanship […]

  18. […] was working on something related when reading Dan’s Programming is not a Craft. I usually view the internet as a snapshot of the recent past not worth dealing with too much on […]

  19. […] North’s original post, that stirred the hornet’s […]

  20. This very long post seems to induce very long responses.

    In my experience, the only thing that matters in most software development is that the project team has at least reasonably intelligent people, with a reasonable amount of training / experience, combined with a good work ethic.

    The last thing you need is zealots. Those who want to do xyz-driven development, who want to do things ‘the right way’, who want to follow the latest methodology trend only serve to bog up progress and fail to deliver a good balance between software quality and project costs.

  21. […] Je ne sais pas si vous avez suivi le monde des blogs anglophones ces derniers jours, mais un débat fait rage autour du mouvement software craftmanship. Une polémique était latente depuis le lancement de ce mouvement en 2009 sur le bien fondé et la signification de ce manifeste. C’était perceptible dans les discours de certains participants à la QCon 2010 par exemple. L’étincelle est venue de Dan North avec son article Programming is not a craft. […]

  22. “*Everyone* can be super! And when everyone’s super…no one will be.” – Syndrome

  23. thinkingbox · ·

    Jace Bennett :
    Art and craft are NOT totally different things, but they do have a key difference, and it cuts to the heart of your thesis.
    Art exists for art’s sake. Crafts are practiced for the sake of profit.
    We’re not talking about software gratia software. We’re talking about considering aspects of our work that the customer may not consider, that he pays us to consider, that will ultimately increase actual value delivered, maintenance cost, maintenance frequency, etc. In a word, craftsmanship.

    Bravo Jace, you nailed it!

  24. tobiasmayer · ·

    I care about the aesthetics of plumbing, and electrical wiring, and plastering, and brick pointing… I care that the people who do the work care about what they do and how they do it. I care because I can trust those people to do the best job they can do, to build quality into their work and not cut corners. And I care because I appreciate the beauty of good craftsmanship for its own sake.

    Plumbing, when done well, is a craft. Digging a hole, if done with care and pride can be a craft. Some gravediggers dig beautiful holes, others do not. You say software isn’t a craft but some programmers are craftsmen. I claim that if we work as craftsmen, we are doing craft.

    In general (except when people work poorly) software development is a craft because we are creating items of beauty. A website has (should have) visual beauty, and usability ease, and speed. A data crunching system, though invisible should be fast, accurate and unintrusive. My GPS should direct me with accuracy and simplicity. These are all aesthetic as well as functional qualities.

    You make some good observations in this article, and call out some bullshit, but I am not sure what you hope to gain by decrying the craftsmanship mindset. Wouldn’t it be better to support those non-craftsmen to write better software, to go beyond the tradesman mindset?

    1. “When I am working on a problem, I never think about beauty but when I have finished, if the solution is not beautiful, I know it is wrong.”

      –R. Buckminster Fuller

  25. twendstream · ·

    Perhaps it’s because there are so many highly educated people around, but a discussion of what our profession IS, doesn’t further the quality and effectiveness of our profession. You said it yourself: “…stop navel-gazing”.

    1. tobiasmayer · ·

      @twendstream I disagree with this. If we don’t reflect on our own profession with an eye to improvement we just keep working in the same old ways, and making the same mistakes.

  26. […] talk over the last few weeks about Software Craftsmanship — triggered by the Dan North’s recent criticism of the manifesto. Martin Fowler seems to think the movement is partly a reaction to the […]

  27. […] blogs which you can find all of them at the end of this post. This discussion originated by this post from Dan North. In all of these discussions Michael Feathers’s article about the […]

  28. Curtis Cooley · ·

    Obviously you’ve never lived in a house plumbed by a shitty plumber :)

    You are absolutely correct that until I’ll lived in a house plumbed by a shitty plumber, I didn’t care about his ‘craft’. I do now. Every time I get to mop watter off the floor and patch a broken pipe.

  29. Probably already said this: absolutely right!

  30. […] 29, 2011 by rubayeet I’ve just finished reading the article “Programming is not Craftsmanship” and couldn’t help but share my own views on this topic. If you haven’t read the […]

  31. So… in your article seems like anybody can do real programming. Just because you do Visual Basic stuff with few drag and drops here and there, that does not mean that cr*p of M$ is the only way to create software. That also does not mean that whom barely knows how to do drag and drop can create applications that will provide enough leverage and features that endure over the time. I seriously doubt that drag-n-drop guys can even hold a job position for long time and even get well paid… thinking on that better, yes, there is some lucky guys that could have that, just like sloppy plumbers, doctors and lawyers and other sloppy professionals in other areas.

  32. […] Dan North: “So what does this have to do with software? Well it seems to me the most [successful] 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.” […]

  33. I agree – to sum up – USEFULNESS matters a lot and not the good looks according to me..

  34. From that long article, I can only conclude that you want other people to value same things and understand certain words (craftmanship) same way as you do.

  35. I really appreciate your post because constructive negative critique is often the most valueful one for improving insights.

    Beside this, the problems, which the SCM movement tries to address, are deeply philosophical because it is somehow a question about the nature of software itself. Particularly the absence of a fundamental theory like physics inside the classical engineering disciplines.

    One resulting difficulty is the concrete measurement of “success” especially from the customers (or also less technical skilled employers) point of view. Why? Because normally only the “it works” measurement is applied, which is normal for physical objects. But, as all software developers know, saying “it works” is incredibly difficult for software. There is also no possiblity to have a kind of formula or a common standard (e.g. ISO) which gives in fact a guarantee that “it works” will hold even before the product will be finally built (which is important because this is often the most expensive part in the physical world – software, in contrast, has no heavyweight “build” part at all)

    I think this is one of the main roots of the confusion and the difficulty. If it is not possible to have a kind of standardized “success” respectively “it works” model, it is also not possible to have a standardized “it works” certification process.

    This difficulties explain also the selection of the “craftsmanship” metaphore. Craftmanship combines physical “it works” measurements with difficult to measure “art” elements on an individual level. The “art” element is the somehow common determiner to software regarding its fuzziness. It is like the hope to “drag-out” the physical element for introducing more “physicality” into the software development community. But the ulimate lack of physicality illuminates the strong focus on the remaining vague “art” element of the SCM which is the also base of the critique of this blog entry.

    How to solve this? I really don’t know ;-)

  36. Oi! North! Noooooo! :-)

  37. Hey Dan, I have come to the conclusion that I agree with what I think you are asserting; however, the critical point isn’t so much craft versus trade as it of utility versus construction.
    Success in software depends on doing the right thing right. The SCM has been focused on the second part of that equation. “Clean Code” ensures that whatever we are going to build, regardless as to whether the utility has been validated, we do it well. In that regard, we can call the code (the implementation meant to fulfill a requirement) “well-crafted”. In addition, part of that craftsmanship ensures that if there is volatility or evolution in the understanding of utility, it can be modify in the most effective manner (usually measured as a matter of time) both in terms of delivering that change and in not breaking things that were not meant to change.
    So I think we can put the gold star on “code craftsmanship” and get behind the work the SCM is doing in this regard.
    The problem is with the first half of the “right thing done right” equation. Imagine for a minute that a plumber installed a toilet and all of the details of the work were executed with the expert hand of a true craftsman, except that the toilet was installed in the wrong place. Now the house building metaphor is problematic for software comparisons for (at least) two reasons:
    1) Most houses are built for living and each job done builds experience in the same problem domain. In software, successive ‘jobs’ are exploring new domains or at the least new areas of existing domains (not the same as patterns, and in fact pushing feature patterns on customers is a problem).
    2) Due to software’s non-material nature, change is much cheaper than rework done for a house.
    Still, the analogy shows why it is hard to confirm the status of craftsman when viewed from the whole software perspective. In terms of requirement (a problematic word, but that’s another discussion), the code craftsman is only offering successive approximation (iteration), and that is not the mark of master craftsman (given Dan’s work in BDD, it’s easy to understand why this irks him so much).
    I admit I haven’t searched every corner, but I don’t see anything from SCM in terms of professional practices in this area. Right there on the SCM home page is a link to “Is Craftsmanship All About Code?,” that acknowledges the need for, and absence of, answers in this area.
    And by no means am I saying that this is SCM’s problem, it is an industry problem. I do have some reservations that the touted code katas may be enforcing patterns of successive approximation that will need to be unlearned.
    I propose that no one bring together the “Software” and “Craftsman” word until there is a non-iterative way to do the right thing right. When that happens, we will have a new set of skills to master to become true software craftspeople, or we will work in a set of related trades than enable coders to have one level of craft, and the overall craftsmanship will reside with home builders and architects.

  38. […] chewing on Dan North’s “Programming is not a craft” post and subsequent reactions for the past couple weeks. I have come to the conclusion that I agree with […]

  39. Here’s the deal from my perspective.

    Back in the 1970’s I studied electrical engineering, computer science, and mathematics (mostly pure maths).

    And since then I have worked essentially as a programmer, but researching and developing my own database tools and functional language to go with it.

    Even back then as an active member of the IEEE I found it hard to understand why I could only be an junior – associate – member of the Australian Computer Society which then (and I believe still) insists on experience over qualification.

    I can’t see the profession (dodgy term in my view, but anyway) really progressing until we develop a proper hierarchy of qualifications and skills.

    It isn’t about craftsmanship, or democratisation, or anything other ‘cool’ terms.

    It’s simply about an industry that needs to mature.

    SO your blog referred to a few industries to do with building mainly without completing the hierarchy.

    Engineering and building start with an elite group of highly skilled individuals studying the laws behind the physics – the scientists; the engineers and architects use the knowledge of the scientist and add design and social/environmental etc sensitivity to design appropriate structures; builders of some sort turn the designs into reality using tradesman skilled in laying bricks, nailing timber, laying pipes, etc.

    This hierarchy is trying to develop in programming and has always existed to some extent, but external efforts to dumb down the requirements fight against the creation of a properly structured industry.

    In my view anything that helps the general public understand that not everyone can be a good programmer is a good idea at the moment.

    These days when someone says – oh you work in IT – I respond by saying no. I’m a computer scientist. I just happen to earn money by programming. What else can you do….

  40. Hi Dan,
    After reading your post I came to the conclusion that the debate might come down to a cultural difference. In dutch we would use ‘ambacht’ which would be like a baker or a carpenter. This translate into ‘craft’ in English. This is in no way intended as the ‘craft’ definition that comes from ‘arts and crafts’ you seem to be using. I do expect software developers to be like craftsman in the Dutch sense: They need to be able to leverage the tools and resources to make a decent product, it being a loaf of bread, a chair or a software product. Mastery in leveraging the tools and resources is given to precious few and for the rest of us it is just hard work.

  41. Finnbarr P. Murphy · ·

    I would argue that programming is a skilled trade and not a craft or profession. Taken to the extreme certain programming can be considered as art just as a skilled tradesman can produce an aesthetically appealing and highly functional product.

    True software engineering on the other hand is a profession and is starting to be recognized as such by other professional societies. Within five years, numerous states here in the USA will be licensing professional software engineers. Texas already does it.

  42. […] a, en fait, démarré bien avant dans la communauté anglophone suite à des articles critiques de Dan North et Martin Fowler et aux réponses de Robert « Uncle Bob » Martin), j’ai […]

  43. Oh, wow! That was a lot of bullshit. You’re doing totally unrelated parallels between art, architecture and coding. If there’s anyone with a big ego it’s you, Dan North.

  44. As long as the programmer is the ol’ “Master Builder”–designer and craftsman in one, NO skyscrapers will be built indeed. A poster above me said it: “It is an industry that needs to mature”.

    Dan, you write:
    “I don’t want “steadily adding value,” I want “amazing their customers every day!”

    That, to me, smells of sales-talk. It sounds like just the “idea-guy” who never managed to piece together anything himself. Sorry. :)

    If the goal is to churn out 20 amazing prototype webapps with one turning out okay and the other 19 scrapped, well thats what we will do.

    If the goal is to build something a bit more serious that must be maintained ten years into the future, you really need steady progress and firm footing.

    Building software is all about its process and very little about actual construction.

  45. […] ein paar Tagen hat Dan North in seinem Blog geschrieben, dass Software Craftsmanship (Handwerk) zu sehr die Software selbst in den Fokus der […]

%d bloggers like this: