A few months ago a prominent figure in the tech and software space was uninvited from a conference[^1]. In an (intentionally humorous) summary of this person, Melissa McEwan wrote a Tech Bullshit Explained about the person. I don't want to talk about any of allegations or (tellingly-immature) reactions to the allegations, but something McEwan said in her post didn't seem to fit, and to me seemed a little too far. She says:
[^1]: I don't want to name them in this post because this isn't about them, or really the situation. Please oh goodness please don't let anything I say here be seen as any critique or defence of anyone or their action.
They had to make Software Craftsmanship because Agile became too much about project management and not about code. This made software devs sad because they hate it when things aren't about them. [Person of Interest] and others thought too much code sucked. And people weren't paying enough attention to writing code that didn't suck. They decided the solution was to LARP as medieval craftspeople. And pretend they were making beautiful woodcarvings instead of pop up windows on websites.
Look, I'm all for making fun of nerds, especially when they put on ill-fitting armour and probably very itchy wool and run at each other in a field, we've all seen Role Models. Just as people make fun of the nerds who have nothing better to do on a Tuesday evening than write things no one will ever read because it feels mildly more productive than watching the third episode of Ru Paul's since dinner.
I don't take issue with calling it craftspersonship or artisanal. We can just go ahead and remove all the needless gendering from our language, it adds nothing and does damage as a whole. I also take some umbrage with the fact that damn near everything is artisanal: ice-cream, every Etsy store, and now apparently anyone who writes code.
I see the humour in the choice of naming: a bunch of engineers get tired of no one else understanding how hard it is to do their job and how clever and skilled they are. So they look around and the only analogy they can find is obviously something right out of a D&D game or fantasy trope: the student/master, artisan/apprentise model.
And finally, yep, we've all met at least one Grumpy Engineer (TM) or Egotistic Engineer (TM). I think in part it's because the salaries are comparatively high (because they provide high value), another part because of the underlying nature of the job, and a further part selection bias for the kind of people who want to become software engineers. It is a good idea to account for this inflated sense of self-importance when making software: give an engineer 1-12 weeks and at some point they're going to demand this awful code needs a re-write because they wouldn't make something this messy. Part of managing and working alongside/within engineering teams is compressing this need for perfection, or the illusion of perfection, in favour of "yes but also we need to satisfy our customers because they pay you".
I do, however, take issue with the idea that we can use these easily mockable and related things to dismiss or diminish the sentiment behind what lead to the need for Software as a Craft (SaaC?). There's a clear underlying point to me, and one that doesn't even start with these old white men - in 1998 Freeman Dyson drew comparison between the historic practice of craft and the modern (at the time) software development.
In his essay Science as a Craft Industry, Dyson puts Craft against Mass Production as two ends of a spectrum. Both approaches have their pros and cons. Mass production has enabled pretty much everything, from water bottles to cars, to become massively affordable and therefore pushed societal advancement as a whole. But mass Production is all about producing one thing: that single factory only pumps out motorcycles or water bottles. It's not going to start producing jigsaws by mistake if you stop watching it for thirty minutes, but nor could you easily turn it into a jigsaw factory very easily.
The original Arts and Crafts movement emerged around the turn of the 20th century in response to increased mechanisation and mass production. William Morris was an even first-er "Old White Men" that McEwan could point at. Morris argued strongly that artists and designers see themselves, and their work, as craftspeople would: working by hand to create the highest quality individual work. The Arts and Crafts movement criticised mass production or mechanisation, at times calling for all work to be done by hand and at other saying that so long as machines could produce work (designed by craftspeople, obviously) of good quality, then it was okay to use them.
In a much more moderate, less social reformist, argument Dyson argues for software as a craft from the perspective that humans are a tool-making species. We will continue to use the materials available to us (physical and conceptual) to craft tools and solutions which help us do things. Mass production may help spread those tools, but we're always going to be tinkering and building - and that is the craft. He argues that software development is just as much a craft as the development of better, more precise, more capable scientific equipment:
Because of the enormous variety of specialized applications, there will always be room for individuals to write software based on their unique knowledge. There will always be niche markets to keep small software companies alive. The craft of writing software will not become obsolete. And the craft of using software creatively is flourishing even more than the craft of writing it (Science as a Craft Industry Freeman Dyson, 1998)
When the production of software is a craft we appreciate, and even require, high levels of proficiency in a the problem domain and the technical tools available. This is what lets someone create, or purposefully work towards creating, software which is better, stronger, more efficient, cheaper, faster, easier to use, more stable, etc. - whatever the problem space demands.
When we see software only as a craft, as something which is entirely small scale in scope and also in team size, we risk producing only small-scale work. Perhaps worse, we risk having pockets of high quality work, undertaken by people who both love the craft, and have the mental aptitude to truly improve the craft. I would argue that software engineers have a duty to share experiences, best practices, evaluations, and tradeoffs. Part of being a craft, then, is the teaching/learning aspect of student and teachers. Though, given the already vast breadth and depth of modern software, all engineers should be coming into the craft with a student's mindset. I digress, though.
Both approaches, software as a craft vs. mass produced software, are necessary. It's a shame that we made the decision to point to the people who made furniture and cutlery 500 years ago and be like "do it like they did it", because they're seemingly very different. However, the fundamental designs of a chair and a fork haven't much changed in the last 500 years, nor have we yet converged on a single utilitarian design for either. Take a metal worker or a carpenter from today and 500 years ago and watch them work, and it probably looks very similar. Now people might learn more from YouTube than they did in the 1500s - and people may not serve a seven year apprenticeship - I'd imagine the two could sit down over a pint and make good conversation.
Ian Martin makes an interesting point related to this: the decreasingly tangible product of code, i.e. that all we have are files on a hard-drive, may make it easy to forget that writing software produces a thing. If you produce a wonky chair or an overly long fork, it's easy to see the quality of work was not great. By calling for a perception of software as a craft, we fight against that ability to forget or not notice the final quality of the product. You could watch two software engineers with different levels of experience, or in different domains, and it wouldn't necessarily be so easy to guess which is which, at least from a distance.
So maybe there is something to be said for the value of software as a craft, for sometimes focusing on the practice of making better, or at least different, software just for the sake of it. It's a shame that some developers get arrogant, zealous, and grumpy enough to give this idea a bad name. No matter how you justify it - as career advancement for yourself, value added to your business, or experience to your users - we should all be seeking to write better code and that doesn't happen by accident - that happens with the careful application and slow refinement of the craft. If you need to wear a leather gauntlet and call yourself Hilda The Blacksmith's Daughter to do that, then sure, buddy, I'm with ya.
See other articles