Is software development a craft? I think this might be a decently long post, so let’s come back to that, to journeyman idealists, and to some of the finer points of what counts as “software craftsmanship” a little later. Before that, please indulge me in story time. Or, backstory time, as it were.
About 7 years ago, I digitally “signed” something called the Manifesto for Software Craftsmanship. Go do a search, if you like. I’m signatory number 6,662. I remember submitting that form with something like quiet but fierce indignation in my soul.
Software Craftsmanship as Caring and Professional Pride
The year was, according to the website, 2010, and I was surrounded by expert beginners. These folks made architecture decisions on the basis mainly of seniority. The longer you’d hung around the company, the more conceptual votes you ‘earned,’ for some dubious definition of the word earn.
The result? A codebase littered with global state, spaghetti, beachheads of copy-paste code, and tortured, meandering God classes. It was like a bomb went off in that codebase. And if you wanted to try to fix it with newfangled concepts like writing unit tests or paying attention to method complexity, you’d hear predictable expert beginner fare. “I’ve been doing this for a lot of years, and I’ve been shipping software just fine without any of that stuff.”
In that role, I slowly earned my way into positions of influence and then decision-making before I left. At the time of my eventual departure, the build executed a growing unit test suite, interfaces existed in the codebase, and I was proud of what I had done. But it was hard fought and exhausting every step of the way.
And I probably wouldn’t have lasted as long as I did without the galvanization of the software craftsmanship manifesto. It spoke to me, and it said, “not only is it okay to care and to have standards — it’s your professional obligation.”
My Evolving View of Software Craftsmanship
As recently as last April, I wrote a post about software craftsmanship making for good business. As a salaried software developer (and company of one, ala Developer Hegemony), you ingratiate yourself more to the business by adopting practices like TDD than you do by competing in algorithm trivia contests that no one who matters can referee. You start to trade in tight feedback loops, predictable deliveries, and things that make your “clients” really happy. And you become more marketable as an app dev pro.
And years before that, I defended the software craftsmanship movement against a detractor. In that post, I argued that the real thrust behind the movement was to establish that software development isn’t an insolvable quagmire of relativism. Some practices work better than others, and to pretend that isn’t true amounts to quackery, and we shouldn’t tolerate quackery.
In general, if you go back far enough on this blog, you’ll find a bunch of references to software craftsmanship. And in these references, you’ll find some themes. I’ve always respected the caring behind the movement, and I’ve always valued the practices: TDD, continuous integration, constant refactoring, etc. And, whenever I talk about software craftsmanship in praising terms, I’m always talking about those practices and the caring that drives them (including in the post about software craftsmanship being good business).
But, truth be told, I’ve never had much use for the term “craftsmanship,” per se. Historically, I didn’t give it much thought one way or the other — it was just branding, like “agile” or “lean.” But over the years people have started to fetishize the craft guild metaphor into titles and practices and even into a philosophical way of looking at software.
And if you fall into this trap, you do so at your career’s peril.
Read More
