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.
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.
Top comments (5)
I hesitated to heart this rather lengthy and, I think, somewhat difficult to parse post. I'm just going to go off the title (though I accept that it might have been somewhat in jest or purposely provocative).
Speaking from my own experience of 10+ years in the industry (i.e. an eternal beginner who's reconciled himself to that fact) I have to say that the idea of treating software as a craft is one of the best and most beneficial ideas I've ever encountered.
The notion that it represents some kind of 'glass ceiling' I confess I find baffling.
If anything, I've found it to be more like a glass elevator.
What I take away from the 'software as a craft' movement isn't TDD, BDD, refactoring or even caring about code quality. It's something even more fundamental than that.
It's taking pride in what we do.
In pushing back against this post, there are three things I want to point out:
1. There's no one religion or ideology for software craftspeople to subscribe to.
Treating our work as a craft, as important, as something we take pride in, has nothing to do with medieval guilds or TDD or extreme whatever. These are merely ideas (valuable or not) that certain people have come up with. But there is no one way to execute the craft that would apply to every situation. If that were the case, then software development would have been automated out of existence long ago. But, by its nature, the execution varies from situation to situation. I would go as far as to say that every execution is unique and one-of-a-kind - just like a musical performance. I think the Japanese phrase "ichi-go ichi-e" captures this quite beautifully.
(I find it funny that we worry so much about software development becoming automated and ceasing to exist as a human profession, and yet we don't apply that notion to other complex human undertakings, such as psychotherapy or science or brain surgery. Perhaps we spend so much of our time in such close proximity to the processes we are automating that we think we are one with them - but we're not.)
This doesn't mean there aren't superior and inferior executions. As with any discipline, as you work on it, you discover flaws and mistakes and learn how to avoid repeating them in future. You mature and grow and perhaps even develop a new technique. Programmers aren't born.
But no one can force you to subscribe to their ideology or vision of what a software developer should be. People can offer ideas. But each craftsperson is free to cultivate the craft within themselves. To cultivate that which they believe is important and crucial, based on their own experiences, empirical knowledge and personal capabilities. There will be schools of thought and clashes of ideas, just like there have been with every field of human endeavour - whether it's music, architecture, politics. But ultimately, as with all of those, each individual has their own mind and their own idea of what it is that they do. And we need a diversity of ideas and approaches to solve the problems of a world that is becoming radically more complex every day.
2. Career and craft don't clash, in fact they're kind of the same thing.
Do you think Beethoven was such a genius that he didn't have to hustle? Do you think Martin Luther King or Ghandi didn't have to market and sell themselves? I mean even Jesus Christ had to deliver his sermons on a giant hilltop and speak in a loud voice so thousands could hear him.
Anyone who wants to do this as a living and be successful has to take full responsibility for sustaining it financially and in every other respect. We must negotiate hard. We must ruthlessly market and self-promote. We must meet deadlines when meeting them is the difference between keeping and losing the job.
Your unit tests and careful designs mean nothing if the business goes under. What would Facebook's investors have preferred - perfect code or a multi-billion-dollar business?
If there's anything a craftsperson doesn't do, it's to mindlessly treat every case in exactly the same manner.
Just as a doctor doesn't faff about with a patient who's on life support and could die any moment, a software craftsperson doesn't faff about unit testing every square inch or drawing the most detailed UML diagram in history, when there's a production issue costing the company thousands of $ every minute.
Taking the situation into account is not compromising your principles, it's applying the right principles at the right time.
Enough of the "tragic hero" mentality! No one benefits from you losing your job because your "dedication to the craft" forced you to spend years perfecting a single code base, whilst neglecting your C.V. and your elevator pitch, only to have the credit for your work go to some rascal in senior management!
Marketing yourself, selling yourself, hustling, bargaining and negotiating, seeking out the highest paid and most prestigious positions - all of these are part of the lot of the software craftsperson. You may even have to take a pointy-haired job title, like 'Head of People' or 'Strategic Leader'. You are not a sell-out for not being sold down the river. Developers should be as aggressive, ruthless, cunning and manipulative as they possibly can be, for the purpose of doing what they love and building a comfortable career and life out of it.
Would you want the top dentist in the world to be some lilly-livered, weak-willed schmuck who accepted underpaid positions and gradually sunk into a pit of despair and boredom, eventually retiring to a life of reading? HELL NO! YOU WOULD WANT HIM WORKING ON YOUR TEETH! If he had to sometimes neglect other people's feelings or focus on his C.V., you would be happy for him to do it. (Ok, I admit to coming off a bit like Jordan Peterson here.)
There is no dichotomy between doing what you love and doing what it takes to get there. The two are the same thing. If you can't sell yourself into a well paid developer role, you don't deserve that role. Simple as that.
3. We aren't as different from other fields as we think
Software developers seem to think of themselves as either gods or vermin. We're either changing the world or we're pathetic underlings who are forced to obey our overlords (bosses, clients, managers, users, etc.).
The truth is, our problems aren't entirely different from the problems of any other profession.
Do architects have to sometimes deal with tight deadlines or confusing requirements? Yes. Might they have to prove themselves all over again in a job interview, even if they've been doing it for 20 years? Sure. Do they sometimes fail to achieve their platonic ideal, due to realities of time, cost, politics, regulation, etc? Almost certainly.
Why do we expect some kind of great "reward in heaven" for what we do? It's just another job. Sometimes I think we should get over ourselves. Yes, it's unique in a way. But that doesn't mean we are exempt from the normal laws of economics, supply and demand, and of course, human nature.
This goes back to the point about career and craft being the same thing. We shouldn't kid ourselves that just because we're good at software, that we can hack around real life and not even bother with careerism, like promoting and selling ourselves. We should have the humility to realise that we share this world with every other human being, and so we have to deal with human problems, not just machine problems.
I would even go to the end and say that the twists and turns of a software developer's career are really the twists and turns of the hero inside of every human being. That life is a constant and ongoing evolution. That there are always booms and busts, good times and bad. Opportunities for recognition as well as theft of credit. That we will always encounter some mixture of problems that the world imposes upon us and problems that we create for ourselves. In navigating the messy quagmire of reality, we can interpret the world in various ways. The point, however, is to change it!
Anyway that's my lengthy, wordy speil. Your post was valuable in that it triggered many thoughts, as you can see. But I have to push back as well, because for me, software is most definitely a craft, and something I will do until I die.
I understand and welcome folks pushing back, as you put it. I certainly have opinions about the software world that (1) might stir controversy and (2) aren't for everyone.
But as kind of an aside and piece of unsolicited advice, have you thought of taking this and posting it as your own DEV article or on your own blog, or both? You've written a ~1,400 word rebuttal with a thesis, supporting arguments, headings, and conclusion -- a fully baked, well conceived blog post, if you want it to be.
I won't begin to try to respond in a comment because the scope is simply too large to do so. But, if you port this to a first-class post, I'll happily tweet/share/whatever it out, because I imagine there are plenty of people that read my stuff that don't agree with all of it and would appreciate contrasting points of view.
Improve the hygiene of your dwelling cubicle, bucko!
Thanks Erik for posting this! To be honest, I didn't know there was a concept such as value proposition or positioning. Are there any other common sense concepts you recommend developers clarify within themselves that are essential as well? I probably have too many blind spots like these, so I just bought your book to figure them out xD. I kind of fell into software by accident, so my view of software was never from a business perspective, but from a love of creating software.
Thanks for buying the book! It's not really specifically an educational/guide kind of thing, though. More my commentary on the software industry.
It's hard for me to think of terms and concepts off the cuff to explain, but I have tended to talk a lot about it on my blog over the years. I'm also a panelist on the Freelancers Show podcast ( devchat.tv/freelancers/ ) where we talk a lot about such concepts as well.