On craftsmanship

Well, I certainly didn’t expect that kind of interest in my last post. In the past I’ve tended to have a few hundred people reading my infrequent mumblings. In the last few days nearly 20,000 people have popped by according to my site statistics, leaving nearly 150 comments. Crikey!

The overriding message I got was that without providing evidence and concrete examples one way or the other, it was all a lot of noise about terminology. One of my intentions this year is to expand on some of the implications of Deliberate Discovery, which fit the bill nicely in illustrating programming-as-a-trade, so my next article is the start of a series of posts along that vein. I’ll let the evidence speak for itself and you can draw your own conclusions.

I’ve been very grateful for the feedback and comments, and the dialogue on Twitter. I didn’t spend as long as I might have editing and cleaning up the article, largely because I’d been tinkering with it since before Christmas, rewritten it twice, and decided it was better to publish early and respond iteratively to feedback. Typical – go out without your best underwear and you get run over by a bus.

The critical feedback generally fell into the following categories:

  • How dare you! You obviously know nothing of which you speak. (Well, you decide)
  • You obviously don’t / have never / no longer code / care about programming. (Not true)
  • You’re using a pretty crappy definition of “craft” to put forward a bogus argument. Here’s mine / Wikipedia’s / my dad’s / a selective entry from a dictionary’s. (That’s not the point)
  • You shouldn’t/can’t compare programming to building / plumbing / fine art / martial arts. (See “On metaphors” below)
  • I’m angry and important so I’m just going to poke you with a stick rather than do any actual thinking. (Meh)
  • Where’s your evidence? I say “craft,” you say “trade,” show me evidence it’s a trade. (My next few posts)

It seems this is a sensitive subject area so I’ll be editing more carefully from now on to try to pre-empt some of the more obvious critiques I left myself open to in the previous post.

On value

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’m not going to mandate test-driving anything (which is a huge about-face from what I was saying a year ago), unless it will help. Copy-and-paste is fine too. (Before you go all shouty at me again, hold off until I blog about the benefits of copy-and-paste, as it appears in a couple of patterns I’m calling Spike and Stabilize and Ginger Cake. You might be surprised.)

I expect a programmer to apply the appropriate amount of rigour, discipline and excellence to any situation. They should be as comfortable hacking together a disposable script as test-driving a complex business calculation or mathematical algorithm, and they should have a good idea – based on experience – of when to adopt each of these attitudes. This to me is simply good, professional workmanship. (More about this in my next article.)

On metaphors

I shouldn’t have to point this out, but based on some of the feedback it seems I need to. Metaphor or analogy highlights a particular aspect of a situation. If I say something is as calm as a millpond, I don’t also mean to imply that it is wet and has lily leaves floating on it. (Yes I’m aware this is a simile rather than a metaphor.)

I used the example of jiu jitsu because I studied it long enough to qualify as an instructor so I know a bit about it. I remember the awe I felt when I witnessed the calm, grace, power and control of two black belts performing their nage-ne-kata – the same thing that I stumbled clumsily through from time to time – at a national competition one year. They got a standing ovation. It was beautiful. Programming is not a martial art.

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.

On certification

I don’t agree with, support or condone in any way classroom- or course-based certification. It’s a ridiculous money-making charade. (Yes, Scrum Master certification, I’m looking at you.) An inexperienced bully of a manager with a certificate is still an inexperienced bully of a manager.

I was attempting to open up a debate on how we might possibly recognise another’s skill and experience if we don’t a priori know them. This isn’t just a theoretical debate, it’s central to good hiring – or engaging outside help.

I have a lot of regard for experience-based and evidence-based qualifications. The way Dr. Patricia Benner applied the Dreyfus model to nursing in the US, for instance, completely reinvigorated the service. The sheer amount of hard graft and knowledge that most MBA-holders I know put into their studies is testament to how hard they worked to get one (and that they didn’t even bother trying until they had enough experience to attempt it).

I guess I’m saying any qualification worth its salt should enable me to see a curve of, or at least differentiate between, people-who-can and people-who-can’t (rather than just showing people-who-paid). A common refrain was that our industry and technologies change so rapidly that there wasn’t a syllabus or set of course content that could be sensibly assessed. I think I agree with this.

Some of the suggestions that came back were:

  • Look them up online! If they’re any good you should find evidence of that in terms of their own online output or other people’s testimonials. I really like this, especially nowadays, but the counter doesn’t hold: I might overlook some great-but-quiet individual if this becomes my core criteria.
  • Have certification. See above
  • Become (literally) a journeyman, where you rove from company to company, working for a roof over your head, building your reputation as you go. I love this idea but it takes some logistics.

Basically this debate is going to run and run. And I’m glad about that. It’s a really hard problem.

On open source

I consider contributing to open source projects an admirable use of time and a good way to practise your programming. However the average quality of most OSS I’ve seen over the years is bloody shocking. It’s utility, however, is undeniable.

One of the most widely used pieces of OSS is the venerable JUnit. Ironically this was thrown together by two guys on a plane on their way to a conference, who had some time to kill on a long flight. Partly this was so one could learn Java and the other TDD. The fact that the two guys were Kent Beck and Erich Gamma demonstrates that a) two smart and pragmatic enough programmers can put together pretty much anything under any conditions in a few hours, and b) you can get enormous utility without having to rigorously test-drive everything. (Although in this case I understand they did use TDD – Thanks Martin Fowler for the corrections.)

As another example, Joe Walnes, my examplar of the incredibly-talented-and-mildly-amused kind of software craftsman (see On craftsmanship, below), had one of his many open source projects rejected by a code repository’s review panel because it was “too simple – there was no point making it into a library.” Turns out it proved quite popular.

Open source software is as variable as any other software. The fact that it’s open source doesn’t say anything about its quality. It doesn’t mean it is not written or hosted by muppets (or genuinely talented people, for that matter – its open source-ness is simply an orthogonal concern). It’s most certainly not an “apprenticeship model,” but it’s a great way for people to read other people’s code (something we are really poor at as an industry), share knowledge and share the wealth of the utility of software.

On productivity

I don’t have any scientifically-valid numbers for software productivity. I have a ton of informal, empirical evidence that a small group of talented individuals can be insanely productive, even compared with other teams of talented individuals. I’ve been fortunate enough to spend the last year living it (and it’s nearly killed me trying to keep up!).

The people I had in mind when I mentioned hundreds-of-times productivity have done things like standing up an entire soup-to-nuts electronic trading stack, from user-facing visualisations of real-time trading data through to fully-automated trading applications – in a few weeks. These are not standalone applications. They talk to (really complicated) financial exchanges, internal back office settlement and reporting systems, and all the usual corporate messaging infrastructure you would expect to see in a medium-sized firm. To use the words of Lewis Carroll, this is, of course, impossible. I’ll see your factor of 10 and raise you 100. It’s not common. In fact it is extremely unusual. But it does exist.

On programming as a trade

Maybe I should have said “programming has far more in common with a trade than it does with a craft.” As with any analogy, of course there are aspects of craft in programming. There are also aspects of craft in plastering or electrical wiring. I can spot the effects of well-executed, skilful workmanship even if I’m not qualified to rate the work itself. There is just much more of an affinity with trade-ness. In the first instance software should be practical and fit for purpose. I want effective, I don’t want fancy.

The guy who fitted my satellite dish ran the cable incredibly carefully around door frames, through walls, hugging the tops of skirting boards – it was virtually invisible – because “I’ve got a wife too, mate.” My house is old. Many attempted refactorings haven’t worked out and have ended in at least partial rewrites. (Uh oh, a metaphor again. I know programming isn’t DIY.)

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.

On craftsmanship

Some people really care about understanding “the Thing” that we do when we try to get computers to help us do stuff. They think about it, write about it and exhibit it in their work and their behaviour. (Thanks, Michael Feathers, for a thoughtful and insightful post.) These people are sometimes called craftsmen. I admire these people.

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.

Some people are just really bloody good at writing software. They rarely blog, they don’t talk or write about software. They just love coding, solve difficult technical or domain problems in innovative and highly skilful ways in a fraction of the time of us regular mortals, to deliver real benefits. They learn a new tool or technology by using it in real work situations and figuring it out as they go. They think all this navel-gazing, posturing and chatter is a bit silly. I admire these people enormously! Some of them like to tease me. I’m ok with that.

Some people care so much about their profession (I’m using the term in a broad sense here to mean what-they-do-for-a-living) that they choose to help other less experienced practitioners in their field grow and develop their skills. They use their own time to write and freely publish material, or provide workshops or classes, out of a desire to raise the bar across the industry. They might go travelling, not only to develop their own skills but to share their skills and knowledge as they go. (And it makes a great odyssey story!) Sometimes they do this enough that people recognise it and call them out as software craftsmen. I think I admire these people most of all, because they are inspiring the next generation of programmers to think like that too.


  1. […] mumblings. In the last few days nearly 20,000 people have popped by according to my site… [full post] Dan North DanNorth.net uncategorized 0 0 0 0 0 […]

  2. You’ll have some interesting issues trying to convince people from abandoning the Pragmatic Programmer (craft) of Mythical Manmonth (art). Many people have created a reputation on supporting these theories, not just the ones selling it as training, writing & certifying, but also the people that just advocate these concepts in the workplace.
    Why accept things that disagree with you position when there is so much to accept that agrees.
    This might take a generation before a new direction takes hold.

  3. “I’m not going to mandate test-driving anything (which is a huge about-face from what I was saying a year ago), unless it will help.

    I expect a programmer to apply the appropriate amount of rigour, discipline and excellence to any situation. They should be as comfortable hacking together a disposable script as test-driving a complex business calculation or mathematical algorithm, and they should have a good idea – based on experience – of when to adopt each of these attitudes. This to me is simply good, professional workmanship.”

    This needs to be printed and handed out on monday morning.

    Take a problem. Analyze it. Devise a solution. Employ the appropriate tool.

    Often that’s a test. Sometimes a spike. Sometimes a trick.

    People forget to stop and think.

    Thanks for writing this.

  4. […] North just replied to the replies, so I guess the discussion will continue for a […]

  5. […] North just replied to the replies, so I guess the discussion will continue for a […]

  6. Arjen Poutsma · ·

    My response would fall in the first category, but that’s only because I know you ;).

  7. I _love_ the “On Craftsmanship” bit at the end.

    I’ve been blessed by working with people such as these early in my career and they shaped me into the developer I am today (one who is continually learning and trying to improve – a guru I am not).

    I’ve since found more like-minded people in London and a large group of us have over the last couple of years formed several communities (Java, Scala, Clojure, Graduate/Undergraduate, CTOs etc) which simply focus on exchanging knowledge, sharing ideas and working together in workshops. Between the various communities we’ve gone from 0 –> ~1800 active members, it’s really struck a nerve here in London and I’ve never had a more satisfying time as a developer :).

  8. Hello Dan,

    Two very interesting articles. However I would like more clarification on how you want to separate skilled programmers, from those that still require training, and from excellent/master programmers and skilled. I agree with most things written, but that is probably because, in my view, they align a lot with what you are trying to make a distinction from, a craft.

    I also have a really hard time myself to separate the definition of trade and craft. To me, a craftsman is used in trade. Actually the definition of a trade to me is that you have skilled craftsman doing it. I know this is just wording, but it is important as you trying to distinguish trade and craft.

    A good craftsman will produce effective, good enough written (that is spend the appropriate amount of time make the code clean enough for the purpose) and deliver value first and foremost.

    Programs are created because they enable something for someone; however the way it is crafted will vastly effect the cost of ownership. Depending on how long you intend to own it should decide the amount of refinement going into it. I think the definition of technical debt is an excellent measure of this.
    Because the process of actually creating something that does this, creating something abstract (a program) from something abstract(an idea), doesn’t fall into normal engineering (that is production processes) many people want to emphasize the difference between this discipline and the all famous building a house/bridge analogy.

    In my view, programming, the process of creating software, has far more in common with the process of creating fine art, without itself actually being fine art than it has in common with building a house or producing cars. The end product is not fine art, far from it, still the process have many similarities.
    In some, very vague sense, the architect creating the blue prints, might be a little bit as programming, you take an abstract wish from a customer and try to realize it, yet it still far from it, as we don’t build the same function over and over as much as we realize entirely new functions not made before, for our customers. The craft of programming though, I think requires the skills of the architect, the carpenter, the plumber and the electrician as well as decent people skills to actually understand the needs of the customer/end user.

    If however, you are trying to address the all too common notion among developers that the code and the language/tools/IDE used to realize this customer value is more important than the actual function, and you tie this notion to an over emphasis on them thinking they are artistic, then I fully agree with you. But I don’t see how this can be tied to them believing too much they are craftsman.

    For instance, if it is far more important to them to use Linux than ever building something for a user in Windows, to the extent that they actually let that influence their skills (or choice of tools) and create a sloppy end result because of this. Or if you cut&paste code from one part of your code base to another (that are conceptually different, but happen to share a function) and that is worse than striking a deal with the devil. Then I agree with you. However all this doesn’t mean it isn’t important to avoid duplicating things, the skill part of our “trade” comes to play when to actually make this distinction.

    All parts of your code base don’t have to be top notch, fulfilling all the best practices, patterns and conceptual beauty. Actually, in my experience, very small parts of your code base require this (read you will get a return on your investment), it is far more likely the code will require a refactoring due to a change in function no matter how much you tried to anticipate extension. That doesn’t mean I wouldn’t want clean topnotch code everywhere if I had the time, it just means I value enabling my end user by instead investing in another function/feature instead. Again the skill comes into play making this informed decision.

    To make these kind of decision requires a lot of experience, which can only be gotten from working with many code bases in different shapes and forms. A class/certification can teach you to never duplicate code but not when to side step the rule.

    Also no class in the world can teach you the humbleness you need to realize that what you write today someone will change tomorrow. This barrier, this connection between code and ego, is something a skilled craftsman will have no issues with, much like a skilled jiu jitsu practitioner isn’t doing the nage-ne-kata to show off, he/she wants to share. This mental journey is why I believe a martial art metaphor is fitting in some sense (it fits just about any skill acquiring process though) and why it is sometimes used to define the programming trade.

    This was much longer than I intended, but I don’t have time to make it more refined(technical debt or good enough?).

    1. Hi Niclas. In the original article I was pretty much trying to say what you’re saying here, that I want to see software craftsmanship applied to the programming trade. Apparently that message didn’t come over so well! Hopefully the next few articles will provide the examples that make it clearer.

      Sure let’s have an apprenticeship model – it’s been working well for centuries. Eager learners should be able to seek out a suitable mentor, or a whole series of them over time, to help them become better at what they do (and to never lose sight of the fact that it’s not about them but about their worth to others).

      I’ve been using and talking about the Dreyfus model of skills acquisition for a few years now, as one approach to this. Folks like Liz Keogh and Andy Palmer have been using it explicitly in their coaching work to great effect.

  9. […] Luckily the slowness to respond allows me to not write somethings because Dan has follow up with this. As he points out in his critical feedback section that correct definitions were not really the […]

  10. Dan,

    Thanks for the series and will be interested in reading. I had wondered if you had time to digest Richard Sennett’s “The Craftsman”. I made some notes http://blog.goneopen.com/2011/01/response-to-programming-is-not-a-craft/ which in summary he outlines the craftsman around:

    * Manual skills to produce things
    * To do things for their own sake
    * A level of freedom to experiment
    * Reward of competence
    * Within the context of a community to meet standards

    He reckons based on this we’re troubled:

    “Developments in high technology reflect an ancient model for craftsmanship, the reality on the ground is that people who aspire to being good craftsmen are depressed ignored, or misunderstood by social institutions. These ills are complicated because few institutions set out to produce unhappy workers. People seek refuge in inwardness when material engagement proves empty; mental anticipation is privileged above concrete encounter; standards of quality in work separate design from execution”

    Keep up the writing.

    1. Hi Todd.

      I haven’t read The Craftsman, but based on your write-up it’s certainly going on my reading list! Thanks for your blog post – I found it enlightening. Of course now you’ve offered me yet another learning model to digest, I’ll have to go explore that and see where I can apply it.

      1. If you are interested I wrote up a talk on Software Craftsmanship relating Sennett’s ideas to TDD and CI. It starts to look at the ideas of how TDD helps in developing skills and finishes on deliberate and necessary practice. I have really liked Sennett’s explicit point that the general techniques of a good craftsperson are: works on the whole; is able to delay; and is skilled in ambiguity. In my own coaching, I often teaching other’s how this relates to test-driven approaches to programming.

        Link to the pdf is at http://blog.goneopen.com/2011/01/software-craftsmanship-and-tdd/

  11. […] 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 it’s good or bad in its […]

  12. > Open source software is as variable as any other software. The fact that it’s open source doesn’t say anything about its quality.

    This remark (the whole section) fails to engage the actual point that I attempted to make. I suppose I wasn’t clear enough, so with apology for my first failure, please allow me to try again.

    What I advocate (and I believe I was the primary advocate of OSS in that thread) is “Open Development (of source).” That is, it’s the openness of the *development* that interests me. The fact that the source itself is open is only a supporting, necessary detail to making the development open.

    What I want is for all the recruitment, training, designing, debating, trade-off-ing, scheduling, delaying, testing, and releasing to be done openly, in public, where it can be assessed by participants and by-standers alike. My initial point was that you can, therefrom, assess the contributions of an individual contributor. You rightly pointed out that it’s also necessary to assess the project and community as a whole; in meager defense, I’ll point out that as a practical matter, you can’t actually do one of those assessments without also doing the other: you have to look over the whole project’s worth of discussion and contribution in order to place the individual in context; you have to understand each contributor’s value in order to “sum them up” into a view of the whole. But, point to you: the quality of the whole project’s openness definitely matters.

    That there are wretchedly bad OSS projects out there is undisputed; we can stipulate that. That, in fact, by numerical measures, the trash is the vast majority I’ll also willingly stipulate. If I felt defensive enough, I’d probably try to point out that most of the wretched “open source” projects are none the less not “open development” projects, but merely the random emissions of some individual’s private work. But I won’t bother with that, let it stand: most open-source software is crap, a doctrinaire case of Sturgeon’s Second Law. The thing is, we all know this precisely because it’s so easy to see. So, skip those; go with the equally visible good projects.

    You also point out that many good developers don’t engage in Open Development. Absolutely true! Heavens, were we looking for some single perfect system that would unambiguously identify 100% of the good, and exclude 100% of the bad? This was vastly beyond my own aspirations. YMMV, but I’ll settle for “enough good developers to get present work done.”

  13. Dan, I enjoyed your posts and found them thought-provoking. I was glad of this post to summarize the comments to the first because I didn’t have the patience to read them. I try to avoid getting embroiled in what I think are philosophical discussions. But I think this discussion is good if it gets us all to think about how we want to improve, how we want our teams to improve, how we can deliver software that amazes and delights our customers (which you noted should be our goal). Thanks!

  14. Hi Dan,

    Very good posts. It made me write my 2 cents on software development, craftsmanship and how to choose a professional (http://bit.ly/ek3j2s).

    In summary:

    – It doesn’t matter if software development is or is not a craft.
    – However, it does matter how to choose a professional.
    – It doesn’t matter how old is a profession and how well defined is the structured model for advancing through levels of skill and ability of this profession, there always will be good and bad professionals.
    – The best way to choose a professional – a software developer, a medical doctor, a plumber or any other professional – is getting references and checking her past work. And a bit of luck always help!


  15. Jim Cooper · ·

    I think you need to be very careful about who you’re aiming your advice at. Since you’ve mentioned it already, please bear the Dreyfuss Model in mind!

    For example, if I find anyone at my current organisation taking anyone’s advice about copy and paste being a valid thing to do, I’m going to apply electricity to their tender parts. Something like 25% of the code in one of their projects is duplicated (one particularly insidious little template to turn what should be 1 line of code into 10 has been used in literally hundreds of places).

    I might be quite happy to violate the DRY principle occasionally if I see a benefit, but most of the developers here do it far too much already.

    Please, please, please don’t encourage bad programmers to get worse!

    1. Copy and paste rocks! I don’t mean copy and paste where something should obviously be abstracted, but copying and pasting something that is conceptually similar is a valuable time saver.

      I would advise against being too zealous about DRY. DRY often = tight coupling, over engineering and complexity.

      1. Jim Cooper · ·

        This is exactly what I meant when I was talking about the Dreyfus Model (or whatever other means of discriminating between levels of ability you want to use).

        If you could see the code I’m sitting in front of, you would understand why you shouldn’t give inexperienced coders (which is what teams here consist of) an excuse to use copy and paste.

        I can tell you that not worrying about DRY at all leads to tight coupling, over engineering and complexity in a far, far worse way than I’ve ever seen by anyone being “overzealous”.

        If I could instill overzealousness (is that a word?) about DRY here I would be a much happier man.

        The main excuse that people here use to justify having ended up with a morass of duplication? Time saving. The result? Every change to the code takes 3 to 10 times as long as it should. Some changes are considered too risky to make at all.

        You need to be careful about using “time saving” as a justification. Minor short term gains can all too often mean major long term pain.

        I would much rather deal with the results of too much concern over DRY than with the results of too little.

        You need to be aware who you’re giving advice to. The programming advice I give my peers or expect to get from my betters is quite different than that which I will give people starting out in their careers.

        So “copy and paste rocks” is exactly the wrong advice to give to my current team mates. They haven’t yet got to terms with why they shouldn’t do that. They have not yet got the experience to know when they can break that rule.

      2. I totally agree with Jim Cooper. It is really dangerous to break the DRY principle.

        Eliminating duplication is one of the key elements of simple, emergent design.

        Though, some guys talk about the “Rule of Three”: you write the code the first time; it’s OK for you to duplicate it the second time; but the third time you must refactor it to remove the duplication.

        There’s a good quote from “TDD by Example”:

        “Duplication is always a bad thing, unless you look at it as motivation to find the missing design element.”

        I collected some other quotes on duplication:

  16. If you curve the programmer community by skill you will likely find a bell. If that’s the case, the bulk of software is written by those of us in the middle, not the outlier rock stars. Why are thought leaders focused on outliers? I don’t watch E! because I don’t care about pop stars… tell me why I should keep reading blogs that only speak about/to rock star programmers?

    Also, if some thought leader wouldn’t mind writing an article about a learning / decision model besides Dreyfus that would be fantastic. The references grow weary. Have a look at Naturalistic Decision Making or heck, even V-Y-J would be good… let’s put Dreyfus to bed.

    1. > If you curve the programmer community by skill you will likely find a bell. If that’s the case, the bulk of software is written by those of us in the middle, not the outlier rock stars.

      You will find more than one hump in the curve. The large one at the left is the one from which the bulk of lines of software are splurted out.

      Badlands of flatness in the middle. Yes, in fact the majority are very much below average in skill and productivity.

      The much smaller hump at the top is the one from where the bulk of useful and used and nurtured and well-built software is made manifest – often from far fewer lines of code and far more attention to detail in far less time.

      This is the one to three orders of productivity Dan refers to. Less code written faster to do more for longer. Call it what you like, but if you have the rare chance to witness it, you never want to go near the left end of the curve again.

  17. […] reading Dan North’s second post about software craftsmanship I was able to resonate quite a lot with a point he made in the ‘On value’ section: […]

  18. I think the Software Craftsmanship debate has become far too polarised. People are becoming more extreme in their positions as the discussion continues. I think that there are values of Software Craftsmanship that we can all agree are good, and then there are aspects such as Certification, which are more controversial.

    The manifesto itself isn’t controversial is it? We all want to write software that is easy to maintain (or “well crafted” if you will) we don’t want to hack in quick fixes when we could actually be in the habit of leaving code a bit better than when we found it, we all want to be part of a community of professionals (look at all these comments!) and work in productive partnerships.

    I also think you can sign up to the manifesto because you aspire to its values, not because you think you already are (or want to be) a coding-ninja or rock-star-coder.

  19. […] « art » et s’attèlent à leur tâche comme le dit Dan North dans son 2e post sur le sujet : They just love coding, solve difficult technical or domain problems in innovative […]

  20. I really have to admit, that I have problems with the definition of craft and trade because I’m not a native speaker and as German speaking individual I used craft and the German word “Handwerk” as identical.

    Through to your post I looked for the words “trade” and “craft”. In the dictionary leo.dict.org “trade” and “craft” have many possible translations to German. Some of the translations are the same for craft and for trade.

    In the oxford dictionary I looked up trade and beside the trading posts I got:
    “craft an activity involving skill in making things by hand…”

    “a job requiring manual skills and special training: the fundamentals of the construction trade”

    So, maybe you would be so kind and explain a little more to a non native speaker where the real differences in trade and craft is. Because in the end the difference in your usage seems to be very marginal

  21. An experienced Brazilian XP’er named Klaus Wuestefeld says that the methaphor for Software Development should be learning:

    “Software Development is Learning. (…) The source code to any particular software system is not a product of what a team has built. It is an expression of what the team knows.”

    Maybe it’s too much of a tautology but good developers are good, pragmatic, efficient learners.

  22. Tradesmen don’t blog about it. QED.

  23. Dictionary Definitions · ·

    a : the business or work in which one engages regularly : occupation
    b : an occupation requiring manual or mechanical skill : craft
    c : the persons engaged in an occupation, business, or industry

    a : a person who works in a job that requires special skill or training
    b : someone who sells or delivers goods (chiefly Brit)

    : an occupation or trade requiring manual dexterity or artistic skill

    a : a person who makes beautiful objects by hand
    b : a person who is very skilled at doing something

    a : a calling requiring specialized knowledge and often long and intensive academic preparation
    b : a principal calling, vocation, or employment

    a : of, relating to, or characteristic of a profession
    b : engaged in one of the learned professions
    c : characterized by or conforming to the technical or ethical standards of a profession

  24. Seneca · ·

    It feels to me like you’ve injected values that you reject into the software craftmanship that aren’t there. Nothing in the manifesto explicitly says that they are using the term craftsmanship as someone making art, nor anything saying that well written code should have artistic value to a non programmer.

    Personally, I’d call a smith in Medieval times a craftsman, and accept it as a synonym for tradesman. I certainly don’t think they smiths went around trying to make outsiders see the beauty of each horse shoe they made and sold.

  25. […] with hard-coded data behind them, designed to get some feedback about techology or requirements. Dan North, who gave me the term, might write more about this later if we ask nicely, but for this post, we can simply bear in mind […]

  26. […] North just replied to the replies, so I guess the discussion will continue for a […]

%d bloggers like this: