Get a Better Word for Software “Craftsman”

by Krishna on January 26, 2011

Ade Oshineye complains that proponents of Software Craftsmanship misunderstand it:

Ill-informed proponents of Software Craftsmanship tend to make the following mistakes:

  • they don’t read anything except the manifesto and a smattering of blog posts. […]
  • they focus on how Software Craftsmanship can benefit masters rather than apprentices.
  • they think that signing the manifesto is the most important part of becoming a software craftsman.

Liz Keogh suggests that opponents of the movement also make the same mistakes. This was all triggered by Dan North’s post “Programming is not a craft”. Martin Fowler, Robert Martin and others have chimed into the debate.

My take on this is that the use of the word “craftsmanship” is unfortunate. It is a word that already has a specific meaning. (Or, if you prefer, this). Many supporters of Software Craftsmanship know this and they freely borrow terms from the guild system, including the terminology of “apprentice” and “journeyman”. And because of this association, it has connotations of elitism and suggests that is exclusive rather than inclusive despite the protestations of the supporters.

Look, I get it. I understand what people are trying to do. Let us try to write better software. Let us write code that we can be proud of. Let us deliver high quality products. Let us not let deadlines and external pressures force us into compromising the integrity of the software. All great ideals.

But the term “craftsmanship” expresses that very poorly. What it is communicating to others is an exclusionary message that you are not a real programmer unless you are writing “excellent” code after spending years practicing the “craft of programming”. And frankly, that is at odds with a world where 20-something developers are creating software that is used by hundreds of millions. I saw a picture today where Twitter would be the 6th largest country if you used user accounts. And everyone is familiar with Twitter’s engineering problems.

The truth is that you *can* (not “will”) deliver working, popular software even if its code is completely horrible. The end user doesn’t see the code. They see the behavior of the code and that is what sells. If the spaghetti code manages to hang together without disruptive bugs and deliver some useful functionality, it may succeed. And we see this all around us. A simple fact being that many of you reading this may be working on maintaining some code in some system actually being used by users (maybe thousands of users). Yes, that is right — if you are maintaining some horrible code, that code is being used by people, otherwise you wouldn’t be working on it.

The Software Craftsmanship movement (and other quality movements) is living in a cocoon which denies this basic fact. It also denies that quality incurs immediate costs in additional personnel, oversight and training (which may or may not be recovered back in the short or long term). It also doesn’t understand real world economics in which there are few salaried white-collar professional jobs as programming offering a good middle-class life (and the possibility of massive riches), and therefore it attracts a huge segment of the population who are less interested in being craftsmen than in the money and the lifestyle.

We need a more humble message that understands these realities and addresses the real problems. Let us take one example. As I said in the last paragraph, there are many (millions?) of programmers who only view programming as a livelihood. They stick to the clock and for them, programming ends the moment they leave the building and only resumes when they enter it again. They don’t think about programming, they don’t read books, listen to podcasts or see TekPub videos. This is a perfectly valid way of life — after all, many white-collar professions (e.g. clerks, customer service) do the same.

How do you get a programmer from that group to write quality code? Do you do that by holding out the promise of being a “craftsman”? Grow up. Do you fire any such programmer and only hire “craftsmen”? Wake up. What you need is more than internal personal drive. You need good processes and good managers to handle them. Not just copy-cat processes from some methodology, but what makes sense in your company environment for your kind of employees for your type of projects.

There is a lot more to criticize about the Software Craftsmanship Movement and similar methodologies, but let me end here by stating the obvious: If you need “further reading” not to misunderstand what it is about, then maybe you need to change the name and the manifesto.

Previous post:

Next post: