Erik DietrichIs 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.
On Metaphors and on The Craftsmanship Practices versus the Craftsmanship Lifestyle
So let me be clear here. For the rest of this post, when I talk about craftsmanship, I'm talking explicitly about the idea that software development is a craft and that we should attempt to approximate medieval craft guilds.
That is the career limiter, not the underlying extreme programming principles this movement re-brands. Test driving your code or deploying frequently to production are not problems for your career.
So, for clarity purposes, I will try to remember to make a distinction on the blog going forward. I'll talk about XP principles to describe the caring and the technical goodness, and software craftsmanship to refer to the affinity for the craft guild metaphor.
And, speaking of metaphors, I should clarify something else as well. Metaphors can be wonderfully helpful, but all of them break down when taken too far, even ones that are almost completely relatable, such as technical debt.
And true believers always take them too far, sooner or later.
My intent here isn't to try to get everyone to abandon this metaphor or to suggest a better one. Heck, as metaphors for software development go, it's certainly less bad than engineering or building construction. Rather, my intent here is to caution you against poor career side-effects that you'll proudly blunder into as you turn yourself into a journeyman idealist.
Increasingly, this blog focuses on helping you become consultants and efficiencers. In other words, I want you to become experts in the business of software, and you don't do that with self-destructive positioning like trying to compete as a "craftsperson."
The Software Craftsmanship Ideal, in a Vacuum
Let's look, for a moment, at the imagery evoked by this term, software craftsmanship. In other words, if you truly come to believe in software development as a craft, with languages, stacks, and test-driving as the tools of your trade, you probably have an outlook like the following.
Uncaring developers who come in at nine and leave at five, copy-pasting their way to buggy releases are commodity developers. They hawk cheap wares. I, on the other hand, am an artisan. I practice my craft at meetups on nights and weekends, bringing my superior skills to bear at my job. So I distinguish myself in the meritocratic world of supply and demand on the basis of quality. I do this the same way that someone who hand carves chairs out of wood competes with Walmart. In a world of mass produced crap, my customers seek me out because I'm better than my competition, because I care, and because of how I do my job and conduct my business.
It's a fairly romantic sentiment.
And, beyond that, it offers the same flood of endorphins that a Horatio Algier story does. Put your nose to the grindstone, stay humble, work hard, produce high quality output and watch as the universe rewards you.
But life is a little more complex than that.
And if you take this tack, you'll never be a consultant nor an efficiencer. You'll bang up against the highest individual contributor salary band, rewarded eventually only by COLAs, no matter how much you improve.
A History of Craft
I won't belabor this too much, as I give it extensive treatment in my latest book, Developer Hegemony. But it's worth a brief tour through the history of the craft guild and craft. There we can see that it never actually resembled the above concept.
Initially, craft guilds were labor cartels in the middle ages. They emerged reflexively to allow merchants to collectively bargain against oppressive taxes at the local government level.
By threatening to withhold key services, they had some leverage, and they carefully controlled price, supply, and guild membership. They did also control quality, but that was an ancillary concern for the guild and more a matter of local government regulation. If they didn't deliver some minimum quality, then the government had no use for them.
So, in the earliest incarnation of craft guilds, there was nothing resembling competition on quality or anything else. Apologies in advance to libertarian guild advocates for any cognitive dissonance you're feeling right now.
Eventually, and coincident with the emergence of capitalism and markets, craft guilds declined. It was between the decline of the guilds and the rise of the industrial revolution that you had the closest thing to the ideal above.
People built stuff by hand because that was the only option. They would have competed on either price or quality, kind of like the two different weapons shops in town in an RPG: the expensive one with few swords or the cheap one with many crappy swords.
That didn't last too long, though, because the Industrial Revolution came along and pretty much tossed all that right out the window.
Craft and Craftsmanship's Role in the Modern World
The Industrial Revolution began with mechanical automation, and has generally thrown the world into upheaval ever since, commercially. A capitalist with sufficient technology could come along and create a better blueprint for a sword than the quality sword maker. He could then take that blueprint and use mass production and economies of scale to manufacture it more cheaply than the cheap sword maker.
The "big box" sword maker could out-compete both of our craftspeople on both quality and price, simultaneously. Or, with the rise of global manufacturing, it could go manufacture a high quality product cheaply somewhere else, and take advantage of geographical arbitrage to compete.
Or, it could do dozens of things that have become possible in the last 200 years. For all intents and purposes individual artisans hand-making things is dead as a serious part of the economy.
Today, craft is more appropriate in the sense of arts and crafts. Hand-crafted goods occupy a tiny, quasi-artistic niche.
People don't buy them because they compete seriously on price, quality, or anything else. Some consumers may cite quality as the reason, but reality is more complex. Hand-crafted goods mostly fall into the signaling realm of what Venkat Rao calls "premium mediocre" purchases.
For instance, I really like IPAs and craft beer. I like to think that my palette can distinguish a micro-brew from mass-produced Goose Island IPA, but I wouldn't wager much on it in a blind taste test.
If I'm honest, this sort of "hand-crafted" beer purchase is more than just an objective evaluation of pleasure or quality.
Production, Marketing and Sale of Crafts
So the main role of modern craftsmanship in the economy is to cater to people that want to be people that own crafts. The production methodology trumps all when you're buying a gourmet pimento loaf or a souvenir for Aunt Lois.
That's how craft markets work. It's not at all how software markets work.
Let's say that I become a modern day artisan -- a purveyor of crafts. Maybe I really like cheese, and I start homemaking fancy cheeses at home and to bring to parties.
Friends and family tell me that these are, like, the best cheeses ever. And, hey, if there's a song in your heart... plus, I kinda hate my dead-end job as a miscellaneous business person at Soul Crushers Inc. So I save up, I quit my job, and I start slinging cheese at local Farmer's markets.
With any luck, this takes off, and I start to eke out, or perhaps even earn a decent living. I focus on my cheeses exclusively: ingredients, methodology, that kind of thing. I make unusual cheeses, and people buy them.
If I build it, they will come.
Why do they buy this type of cheese? What value do they extract from it? What itch does it scratch in their life?
I dunno, man. What do I look like, a psychologist? You want those answers, ask someone else. I'm an artist -- all about the craft.
I just make cheese.
The Software Craftsman View of Production, Marketing, and Sale of Software
The software craftsmanship model vaguely fails to land in all incarnations. Medieval guilds were labor cartels that "competed" via monopoly and guaranteed quality because they had no choice.
Modern craftsmanship elevates how you build the thing over what you build, why, and for whom. Neither of those things really resemble the actual business of software development.
Oh, there is sort of a superficial resemblance in terms of how software developers act these days, particularly those invested in the craftsmanship as craft guilds movement. We act like artist-style craftspeople, and we tout the "how" above all else. We believe that our differentiator and our positioning is, like our artisan cheese maker, all a matter of how we approach our "craft."
But unlike artisan cheese-makers, we can't hand out little bites of software to prospective buyers. We have no way of showing non-developers the "how" of heretofore unwritten software that they're buying. So, we signal the how in other ways.
We wear Github T-shirts and casual dress (craftspeople are all about the craft -- not the superficial stuff that pleases The Man). We emphasize technocratic minutiae, lecture buyers on the importance thereof, and show up with fancy techs and strong opinions about them. And we literally tell them that we are craftspeople, in case the rest of that signaling somehow missed the mark.
The Actual Production, Marketing, and Sale of Software
The problem is, as I said before, buyers of software development do not care about this stuff. And, frankly, neither do our bosses. But neither our buyers nor our bosses are the target market, so to speak, for all of this cultural craftsmanship/guild stuff.
We are. It's theater for software developers.
Software developers are expensive, hard to find, hard to retain, and hard to keep happy. So when we show up to work, telling people that we want to be called artisans and that our work is an art form, they think, "alright, Bob's your Uncle, buddy."
And when we tell them that we're not so interested in the particulars -- we just want to focus on the art of crafting software and let them sort out the rest, they think, "wow, okay, that's... even better."
And when we want to establish secret orders of craft and apprenticeships and whatnot and slow down the wheels of promotion until people have mastered things, they start thinking, "okay, okay, what's the catch?"
They humor us, even as they think this stuff is silly.
"Sure, yeah, I get that. You have to stand on principle. SDD or TDD or UDD whatever you said is super important. Yep, and inversion of change. You are a true master software craftsman or whatever you're calling yourself these days."
Next to how hard it is to find and retain you, they'll let you wear what you want, call yourself what you want, and do whatever you want, as long as you turn their specs into code. This holds doubly true given that the kind of talented people that care enough to elevate their work to an art form tend to be really efficient at turning those specs into that code.
The Journeyman Idealist Glass Ceiling
I usually think of journeyman idealists as algorithm trivia buffs, gleefully playing stump the chump. But it can also take the form of somehow viewing writing web service glue code as on par with creating some sort of sculpture, that others might bask in its aesthetic beauty.
Journeyman idealism happens when we entertain meritocratic delusions of grandeur, letting people weaponize our own desire for mastery against us.
So let's say you find yourself in this situation. You think of craft guilds not as labor cartels and craft not as selling hand woven baskets.
Instead, you think of craft as you competing (and winning) with the rest of the world on the basis that you have better technique than those around you. You think you're hand-making works of art.
Even if that's not strictly true, what's the harm to your career, when people are pleased with your work? Why is this bad?
It's bad because you fundamentally misunderstand your own value proposition and positioning. And that's a bad look for any professional, let alone someone that wants to sell herself as a consultant, an expert, an efficiencer, or someone that understands the business world. It's bad because the people buying your labor and the people to whom you're reporting converse with you in corporate babytalk.
The Actual Positioning of XP Principles (and Thus Software Craftsmanship)
If you start to dig into the rationale for these approaches, you're going to start to notice a different theme. When it comes to these practices, why do we do them, and why do we tell people that we do them?
You practice TDD for a lot of reasons, but among them you have avoiding gold-plating (minimizing waste), catching defects early (efficiency), guarding against regression defects (saving future work). This keeps your code clean, which keeps the feature velocity constant (predictability) and the code more maintainable (lower risk).
As you go through more "craftsmanship" practices, you'll start to see a pattern. Sure, you can talk about software quality and some other things, but all of this is aimed at lowering the software's total cost of ownership over the long haul. It all speaks to the wisdom that "the only thing more expensive than a good software development team is a bad one."
When you practice these principles, your differentiator and your value proposition relative to competition is that you're less expensive. You're not a guy selling $20 blocks of cheese at the farmers market. You're WalMart.
And the sooner that you realize that, the sooner you'll stop looking to the wider world like a WalMart employee singing the virtues of WalMart's artisanal, hand-crafted folding chairs.
