I’ve been reading Dan North’s post on programming as a craft, and Adewale Oshineye’s response. I also don’t view programming as a craft. I believe that programming is merely the vocabulary in which we express our craft or trade (and I’m ambivalent about the difference between craft and trade). Focusing exclusively on programming is like learning how to write excellent essays, poetry and email, when 70% of our communication is non-verbal. However, within that limited sphere, I do care about being fluent in our vocabulary, and I think that the people involved in the SC movement and I pursue many of the same goals. I would be surprised if any of us pursued those goals exclusively.
This post is more about the Software Craftsmanship manifesto, whose existence discomforts me.
I dislike the wording of the manifesto’s points because I don’t think they differentiate between programmers who genuinely care about the value they deliver, programmers who care about the beauty of their code, and programmers who hold a mistaken belief in their own abilities. Any software developer – even the naive, straight-out-of-college engineer with no knowledge of design and little knowledge of incremental delivery – could sign up to that manifesto in the mistaken belief that they were doing the things it espouses. I used to be one such developer, so I speak from experience.
I dislike the statement, “That is, in pursuit of the items on the left we have found the items on the right to be indispensable.” Indispensible? Absolutely necessary and requisite? Plenty of valuable code has been delivered by individuals trying out a new idea on their own; by coders like my dad who can’t make a maintainable product to save their lives, but who can rewrite it if they need to; by parties who started out on a basis of distrust and only learnt collaboration later on, let alone partnership; by people who couldn’t find the software they needed so wrote it themselves, or discovered unintentional value and responded to the change. If that phrase read, “That is, the items on the left are a good start and we would like to help you pursue the items on the right too,” it would be a less elitist message. For those developers who would like to be better, and who are aware that they’re learning, the manifesto casts them into the role of the “others” which Software Craftsmen are “helping to learn” the craft. I guess I’m one of those “others”, because I’m still learning about the items on the right, and I certainly can’t see myself as one of the craftsmen with the manifesto phrased in the form it currently takes.
Ade has outlined a number of mistakes which proponents – and I believe opponents – make regarding the software craftsmanship movement. I think supporters of the manifesto are doing exactly the same thing; failing to look at the background of the movement, and jumping on a bandwagon which lets them concentrate on the things they find stimulating while ignoring the bigger picture. “The glamour is overtaking the intent”, as Dan North put it. If Dan’s post does nothing but address the glamour and steer developers away from indulgence in the technical intricacies of their work – refactoring to oblivion while failing to deliver, focusing on test coverage while the company continues to leak money, worrying about the latest testing tool while failing to talk to stakeholders, or insisting that no one can interrupt their two-week sprint once they’ve made a commitment, for instance – then I applaud it.
I particularly liked the conversation between Dan, Aviv Ben-Yosef and Jason Gormand over Twitter, in which they concluded that Software Craftsman is a status you should be awarded by someone else. If nothing else, Dan’s post has let us have a conversation about what craftsmanship really means; a conversation which should be at least as public as the manifesto itself.
Ade, a further reading section attached to the manifesto is an excellent idea. Without it, that manifesto is the face of the Software Craftsmanship movement. I don’t much care for the expression on that face.
Liz Keogh, lunivore 
Hmm. I’m not out of the thicket on this one. If programming is ‘vocabulary’, I get drawn to writing (vocabulary and grammar in service of making the writers’ point/telling the writer’s story)… and writing is often referred to as a, wait for it, craft. This is slippery stuff, language.
Hi Liz,
I’d be interested in your take on this in terms of the Dreyfus learning model? Where I currently work there is a big debate going on about gut-feel vc data based decision making, with proponents for the former arguing for it on the basis of being “expert”. However it seems to me that being a software craftsperson – or “expert” in general – is, like scientific hypothesis, something you can only disprove. The problem is we only have an idea about the competence levels beneath us. We never have knowledge of all the additional areas about which we still know nothing until we meet someone more knowledgeable than us and suddenly realise ‘wow I thought I knew what I was on about, but now realise there are a whole load of other topic areas I never even knew existed’…
Julian
Hi Julian,
It’s possible to get a knowledge of the next level up by looking for role models; experts in the space into which you want to move. I don’t think the manifesto actually helps us recognise those experts, though. It’s a label which someone else has to assign. I find it more useful to worry about progression and improvement than to worry about who’s an expert and who’s merely knowledgeable.
I also find the Dreyfus model works at a much more fine-grained level than simply “programmer”. You don’t get expert programmers; just expert algorithm devs, expert TDDers, expert pair-programmers who make you feel awesome, expert architects, expert UI devs, expert C# devs, experts who are awful at development but can explain what’s going on to the non-technies, experts in automation; experts in Selenium… and when you start analysing people’s skills like this, you find out that *everyone* has a ton left to learn, and most people have extensive knowledge in something, even if they’re not an expert.
Re gut-based feel vs data-based decision making – I’m on the side of data. If I get a gut-feel I try to look at what it is I’ve observed that’s giving me the gut feeling. Interesting patterns emerge when I start paying attention to my own observations, and saying “They’ve all got their heads down and nobody’s talking to each other, so the code’s going to be unreviewed and unmaintainable” is far more compelling than “You scared them so now they’re cutting corners.” But I still don’t think the initial gut feel makes me an expert coach, and I don’t think that gut-feel about code – which I’ve had to some extent since I picked up a BBC Micro B at the age of 7 – ever made me an expert programmer.
BTW, your work on the memes has really helped inspire me with the BDD book writing. Thanks!
Honestly, I don’t think it matters whether folk call what they do “craft”, “art”, “engineering” or just plain old “computer programming”. The end product has the last word, always.
Pingback: George Dinwiddie’s blog » Software Craftsmanship
Pingback: Software Craftmanship | The Art of Software Development
Pingback: thekua.com@work » Speaking at QCon 2011
Pingback: Patrick Kua: Speaking at QCon London 2011 | Software Secret Weapons
I believe there’s space of everything. No one thing can satisfy everything. It’s like having an object with too many responsibilities. Not good. Here’s what I do to become better at what I do.
1. For software development process, I learn, Waterfall, Agile and the methodologies under the umbrella.
2. For kick-ass coding skill, I follow the SC way. I creating a space for me to practice coding so that when I need to get things done (a different space) I can do it better. Never mix practice with getting things done (getting paid).
3. For understanding human nature, I meditate, read psychology related book and go to workshops with lots of group hugs.
Everything has a place. Human being is a complex beast. Complexity can only be understood if I’m open.
Pingback: Bliki: CraftmanshipAndTheCrevasse | Software Secret Weapons
Pingback: Martin Fowler: Bliki: CraftmanshipAndTheCrevasse | Software Secret Weapons
Pingback: Software craftmanship | Barre Verte !
Hi Liz,
Thank you. You have finally expressed coherently why I feel so uneasy about the existence of the manifesto.
To me it’s like an intellectual land-grab. I had the same uneasy feeling about Scrum. Jeff Sutherland may have “invented” Scrum but many people had been using the same techniques and process for years before without feeling the need to stick a label on it.
I care about delivering valuable outcomes and have done for years; it’s just in my nature. I don’t need a manifesto to tell me what I already know. Do the folks that need to care the most even know about the SC manifesto? I think sometimes the “community” needs to remember that it is only representative of a tiny fraction of the developers out there at large.
Ruaridh
The thing I personally dislike about the Software Craftsmanship manifesto is that it’s a manifesto. You either need to dilute the message to be inclusive, or specialize it too much and alienate potential signees. That makes writing or signing manifestos a bit of an exercise in futility.
WRT whether or not programming is a craft, I’m inclined to agree with you and say it’s not. It’s more like a vocabulary, or a toolbox. Software engineering, on the other hand, appears more like a craft. It’s a more inclusive term that can be used to cover programming-related aspects of a trade such as software architecture, or non-programming aspects such as listening to customers.
If you want to quote Wikipedia on Engineering, the first paragraph is: “Engineering is the discipline, art, and profession of acquiring and applying scientific, mathematical, economic, social, and practical knowledge to design and build structures, machines, devices, systems, materials and processes that safely realize improvements to the lives of people.”
“Discipline, art and profession”, where presumably “art” is meant more in the “artisan” than the “artist” sense, if you look at the rest of the paragraph.
>they concluded that Software Craftsman is a status you should be awarded by someone else.
Be careful we might end up with a CSC. 😉
But if we want to do that, http://www.entagle.com might the the tool to do it.
ah that should have been http://entaggle.com/
Pingback: For and Against and For Software Craftsmanship -LeadingAgile
Would you have liked it better if it were written like this? https://8thlight.com/blog/uncle-bob/2013/02/10/ThePrinciplesOfCraftsmanship.html
I still don’t view software as a “craft”, and increasingly I’m finding that the focus on high quality is causing people to invest prematurely in ideas that haven’t been validated. Spikes and prototypes are truly important. They don’t have to be high quality – in fact, the mindset needed to quickly get spikes up and running is at odds with all of the “shippable increment” and “working software” language commonly used in agile teams. A focus on craft and quality (for however it’s being defined) is appropriate in some contexts, but not all of them; that awareness is missing from all the manifestos. So it’s OK, as long as it’s called out as a contextual focus, and treated as a centred community (“here are some good things you could try”) rather than a bounded one (“you’re not a craftsperson unless you’re doing these good things”).
I’m hoping to talk more about this, as well as the need for obliquity and serendipity, later this year.