How Might Software Craftsmanship be a Career Glass Ceiling?

Recently I read Software Craftsmanship as a Metaphor is a Career Glass Ceiling by Erik Dietrich. In it he raises an interesting idea, that the craftsmanship metaphor may prove to be career limiting: not in the sense that it will get you fired, but rather that it will put a ceiling on your progress. He does not disparage our practices: his article is not a diatribe against test-driven development or anything like that. His concern rather is that the idea of craftsmanship may be an excuse for developers to put their heads in the sand and ignore the context in which they work: to focus exclusively on the how of coding and not consider why it is being done in the first place. I think this would be most unfortunate but I can imagine some devs would interpret it this way.

It's no secret that the company I work for, Codurance, believes strongly in craftsmanship. The company was born out of the London Software Craftsmanship Community, and the word is liberally sprinkled all over our website (probably a bit too liberally). Company co-founder Mashooq gave a talk at last year’s LSCC conference on how, in his opinion, craftsmanship in software is not a metaphor but a literal truth. But the the leading lights of software craftsmanship have always emphasised professionalism as an essential aspect, and that seems to be the missing part that Erik has identified.

According to Uncle Bob, one of the goals of the agile software development movement, like eXtreme programming before it, was to bridge the chasm that had grown between business and programming. The legions of “agile coaches” who flooded into the industry in the 21st century inadvertently thwarted that goal, because most of them have no experience in computer programming. The effect of this was that “Agile” became all about process, and not a particularly pleasant process at that. Scrum has a long history, dating back to the 1980s, and I don’t know what it was like as originally envisioned, but the experience of working in a 21st century scrum team is all too often that of being in a silo. Worse, the incessant micro-management and lack of influence on long-term planning or strategy or, indeed, anything other than short-term “business value,” forces the unhappy devs into a state of perpetual juniority. Small wonder that any self-respecting programmer who values their labour looks for an alternative, and it does nothing to dispel the unfortunate idea that the only way forward in programming is to go “up” into management.

So the appeal of craftsmanship may be obvious to a programmer who enjoys their job and wants to do it well. It explicitly recognises their technical skill as both necessary and valuable, something that got lost in the Agile revolution. But beware going completely over to the other extreme, and immersing yourself so deeply in your craft that you never come up to view the landscape around you. This is how, as Erik says, it will come to limit your career if you want to grow beyond being a mere order taker. The chasm between business and software development is wider than ever, and it needs to be bridged as a matter of urgency. If you want to help bridge that gap, if you want to give people your advice as well as your expertise, if you want to help them understand what their requirements really should be as well as help fulfil them, then more is needed. You need to understand their particular business for a start, and something of business in general, not to mention you need to possess “soft” skills such as politics, diplomacy and the art of persuasion. These are the skills of a consultant.

(If that’s what you want to do. If you’re perfectly happy writing code and you’d rather not be bothered with anything else, then fine. Go forth, write code, and be happy!)

Personally, I always figured that the term software craftsmanship will eventually outlive its usefulness. I’m not convinced that point has been reached yet. However, I assumed that it would go the same way that agile did: become co-opted by management consultants, turned into a brand and emptied of all its meaning. Maybe, instead, it will be programmers themselves who turn craftsmanship from a badge of pride into a disparaging sneer.

One way or another, at some point we will probably stop using that word to signify what we think important in software development. But the things that we value won’t change: delivering software on time, at reasonable cost, that performs its task well, and maintaining it such that the cost of change does not increase over time. To do these things will always require knowledge and skills acquired through long and varied experience. My hope is that, one day, no special sign will be needed to communicate these things.

We will simply call it software development.