TL;DR
Ill-informed proponents of Software Craftsmanship tend to make the following mistakes:
My fellow ex-Thoughtworker, Dan North, recently wrote a blog post entitled Programming Is Not A Craft. I knew he'd been working on this and I was looking forward to reading a nuanced critique by someone with a long history in the Agile movement. I assumed that Dan would invest time in background reading and bring valuable new insights to the discussion. I was disappointed. He manages to write a long article in which he cites precisely one source. Unfortunately that's an Infoq page about Eric Meijer. His post ends up criticising a straw man version of the Software Craftsmanship manifesto by never quoting or linking to it.
If the manifesto was the only artefact we had then many of his points would be valid. Manifestos tend to skim over lots of complicated issues precisely because they are manifestos and are written to excite rather than explain. We have books, conferences and mailing lists for people who want to ask awkward questions about the details. Unfortunately some of the people who signed the manifesto or who are writing or presenting about Software Craftsmanship appear to have only read the manifesto. I wish some of these people would at least read the Wikipedia page. Or visit one of the companies that base themselves on the Software Craftsmanship model such as Obtiva, 8th Light or Eden Software. In an ideal world people would read McBreen's, admittedly flawed, book or Apprenticeship Patterns (also available online) or even Richard Sennett's The Craftsman. However in the real world people who like the notion of being a blacksmith or have seen too many Japanese martial arts films latch on to the perceived glamour of the manifesto and see it as a way to be associated with those ideas without ever doing the hard work of understanding them.
So as I read Dan's piece I was increasingly baffled. He appeared to be writing a parody of the worst aspects of the software craftsmanship movement. His article makes many of the mistakes that nuanced critics like Ravi Mohan, David Harvey and John Daniels have accused the Software Craftsmanship movement of making.
Firstly he doesn't define his terms. If you're going to say that X is not a Y you need to be very clear about what you mean by X and Y. When I refer to Software Craftsmanship I mean "a community of practice united and defined by overlapping values" and the book goes on to list many of these values.
When it comes to the tricky problem of defining craft, Dave Hoover and I wrote "The dictionary definitions for simple words like craft, craftsmanship, apprentice, journeyman, and master are insufficient for our needs in this book. They are often circular (with craft being defined in terms of the skill a craftsman possesses, a craftsman being defined as someone who exhibits craftsmanship, and craftsmanship being defined as the quality that binds together the craftsmen working in the craft tradition), seldom grounded in the history of the guild system in specific countries, and often generalized to describe anything that is skillfully constructed. In short, these definitions fail to exclude anything and so include everything."
If you still want a definition then I recommend the one from Wikipedia: "a craft is a branch of a profession that requires some particular kind of skilled work. In historical sense, particularly as pertinient to the Medieval history and earlier the term is usually applied towards people in small-scale production of goods."
Dan also makes several allusions to plumbing, martial arts and silversmiths. However this reasoning by analogy obscures his points so much that when he starts conflating art and craft it passes unnoticed. He transitions smoothly from discussing his wife's artistry to talking about programmers moving information around rather than crafting software to talking about cathedrals that you don't realise that he's begun using the words "art" and "craft" interchangeably. Although the phrase "art of plumbing" in the line "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" was a clue.
I'd be the first to point out there's a tension in our industry between art and craft. We even wrote up a pattern about finding ways for dealing with that tension. It starts out with a quote from Richard Stallman: "Craft means making useful objects with perhaps decorative touches. Fine art means making things purely for their beauty." Of course if you conflate the two things then Software Craftsmanship must seem like mere self-indulgence at the customer's expense. Consequently you can make the argument that programming is not a craft if you've effectively redefined craft to mean a focus on gold-plating or aesthetic concerns rather than utility.
I'd usually ignore a blog post as muddled as this except that Dan then proposed a rather worrying set of solutions to the current state of Software Craftsmanship. He suggests creating a new manifesto which is "feisty, opinionated, brash" as well as a Software Craftsmanship Council that would provide accreditation. This would be bringing back exactly the kind of restraint of trade that helped kill off the guild system in Western Europe. It's precisely the kind of closed shop that would drive a wedge between developers and everybody else who plays a role in getting useful software into the hands of real people.
Guilds may have been a necessary evil in medieval Europe but Software Craftsmanship is not about bringing them back. The Software Craftsmanship movement is at least partly about finding ways to include more people in software development. We focus heavily on ideas like apprenticeship, sharing knowledge and deliberate practice rather than on ways to enrich a small coterie of self-proclaimed 'masters'.
The funny thing is that I agree with many of Dan's points about the value of skill, the relative youth of our craft and the importance of focussing on delivering value to our customers. There's just a lot more to the Software Craftsmanship movement than you'll get from skimming the manifesto and I hope that once Dan's taken a look at the rest he'll write something that lives up to my expectations of him.
In the meantime, perhaps we should add a Further Reading section to the Manifesto's website to help reduce this kind of confusion?
Add comments on Buzz
Ill-informed proponents of Software Craftsmanship tend to make the following mistakes:
- they don't read anything except the manifesto and a smattering of blog posts.
- they overlook books like Software Craftsmanship, Apprenticeship Patterns (which has dozens of references in the appendix looking at the nature of expertise and the mechanisms for the acquisition, transfer and enhancement of skill ) and The Craftsman.
- they don't define terms like craft or art so they end up thinking Software Craftsmanship is some code-obsessed mishmash of martial arts and carpentry or plumbing.
- they focus on how Software Craftsmanship can benefit masters rather than apprentices.
- they think that signing the manifesto is the most important part of becoming a software craftsman.
My fellow ex-Thoughtworker, Dan North, recently wrote a blog post entitled Programming Is Not A Craft. I knew he'd been working on this and I was looking forward to reading a nuanced critique by someone with a long history in the Agile movement. I assumed that Dan would invest time in background reading and bring valuable new insights to the discussion. I was disappointed. He manages to write a long article in which he cites precisely one source. Unfortunately that's an Infoq page about Eric Meijer. His post ends up criticising a straw man version of the Software Craftsmanship manifesto by never quoting or linking to it.
If the manifesto was the only artefact we had then many of his points would be valid. Manifestos tend to skim over lots of complicated issues precisely because they are manifestos and are written to excite rather than explain. We have books, conferences and mailing lists for people who want to ask awkward questions about the details. Unfortunately some of the people who signed the manifesto or who are writing or presenting about Software Craftsmanship appear to have only read the manifesto. I wish some of these people would at least read the Wikipedia page. Or visit one of the companies that base themselves on the Software Craftsmanship model such as Obtiva, 8th Light or Eden Software. In an ideal world people would read McBreen's, admittedly flawed, book or Apprenticeship Patterns (also available online) or even Richard Sennett's The Craftsman. However in the real world people who like the notion of being a blacksmith or have seen too many Japanese martial arts films latch on to the perceived glamour of the manifesto and see it as a way to be associated with those ideas without ever doing the hard work of understanding them.
So as I read Dan's piece I was increasingly baffled. He appeared to be writing a parody of the worst aspects of the software craftsmanship movement. His article makes many of the mistakes that nuanced critics like Ravi Mohan, David Harvey and John Daniels have accused the Software Craftsmanship movement of making.
Firstly he doesn't define his terms. If you're going to say that X is not a Y you need to be very clear about what you mean by X and Y. When I refer to Software Craftsmanship I mean "a community of practice united and defined by overlapping values" and the book goes on to list many of these values.
When it comes to the tricky problem of defining craft, Dave Hoover and I wrote "The dictionary definitions for simple words like craft, craftsmanship, apprentice, journeyman, and master are insufficient for our needs in this book. They are often circular (with craft being defined in terms of the skill a craftsman possesses, a craftsman being defined as someone who exhibits craftsmanship, and craftsmanship being defined as the quality that binds together the craftsmen working in the craft tradition), seldom grounded in the history of the guild system in specific countries, and often generalized to describe anything that is skillfully constructed. In short, these definitions fail to exclude anything and so include everything."
If you still want a definition then I recommend the one from Wikipedia: "a craft is a branch of a profession that requires some particular kind of skilled work. In historical sense, particularly as pertinient to the Medieval history and earlier the term is usually applied towards people in small-scale production of goods."
Dan also makes several allusions to plumbing, martial arts and silversmiths. However this reasoning by analogy obscures his points so much that when he starts conflating art and craft it passes unnoticed. He transitions smoothly from discussing his wife's artistry to talking about programmers moving information around rather than crafting software to talking about cathedrals that you don't realise that he's begun using the words "art" and "craft" interchangeably. Although the phrase "art of plumbing" in the line "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" was a clue.
I'd be the first to point out there's a tension in our industry between art and craft. We even wrote up a pattern about finding ways for dealing with that tension. It starts out with a quote from Richard Stallman: "Craft means making useful objects with perhaps decorative touches. Fine art means making things purely for their beauty." Of course if you conflate the two things then Software Craftsmanship must seem like mere self-indulgence at the customer's expense. Consequently you can make the argument that programming is not a craft if you've effectively redefined craft to mean a focus on gold-plating or aesthetic concerns rather than utility.
I'd usually ignore a blog post as muddled as this except that Dan then proposed a rather worrying set of solutions to the current state of Software Craftsmanship. He suggests creating a new manifesto which is "feisty, opinionated, brash" as well as a Software Craftsmanship Council that would provide accreditation. This would be bringing back exactly the kind of restraint of trade that helped kill off the guild system in Western Europe. It's precisely the kind of closed shop that would drive a wedge between developers and everybody else who plays a role in getting useful software into the hands of real people.
Guilds may have been a necessary evil in medieval Europe but Software Craftsmanship is not about bringing them back. The Software Craftsmanship movement is at least partly about finding ways to include more people in software development. We focus heavily on ideas like apprenticeship, sharing knowledge and deliberate practice rather than on ways to enrich a small coterie of self-proclaimed 'masters'.
The funny thing is that I agree with many of Dan's points about the value of skill, the relative youth of our craft and the importance of focussing on delivering value to our customers. There's just a lot more to the Software Craftsmanship movement than you'll get from skimming the manifesto and I hope that once Dan's taken a look at the rest he'll write something that lives up to my expectations of him.
In the meantime, perhaps we should add a Further Reading section to the Manifesto's website to help reduce this kind of confusion?
Add comments on Buzz
No comments:
Post a Comment
Note: only a member of this blog may post a comment.