Danger! Software Craftsmen at Work.

On October 12, 2010 at QCon David Harvey gave a talk entitled Danger! Software Craftsmen at Work.  This talk was nicely summarized and expanded upon by Gael Fraiteur in his blog: Why Should We Care About Software Craftsmanship?  Part 2.  But I have a few things to add.  


Harvey makes the following points (as described by Fraiteur):

1. The Manifesto for Software Craftsmanship is empty of content because it is not refutable, i.e. it is not possible for a reasonable person to disagree.
   
2. The opposition of software craftsmanship to software engineering is pointless and may even give permission to software developers to ignore the lessons of software engineering.
   
3. Metaphors, and the language we are using to describe ourselves and our activity, do matter. The people around us think of a craftsman as someone producing leather bags, not items you can rely on. Although software developers have their own definition of craftsmanship, what eventually matters is the perception of our customers. By choosing inappropriate metaphors, we are increasing the gap between those who build software, and those who use it. 

The Empty Manifesto
Is the Manifesto for Software Craftsmanship empty because it is irrefutable?  I think the notion is absurd.  That's like saying that the Hippocratic Oath, or the Golden Rule are empty because they are irrefutable.  The Manifesto is not a scientific hypothesis that requires experimental verification.  Rather the Manifesto is a statement of beliefs and values that the signatories adhere to and promote.  The Manifesto contains articles of belief, not statements of measurable fact, and is therefore not required to be falsifiable.

Is the Manifesto irrefutable?  Would that it were so!  Unfortunately the Manifesto is regularly refuted in both word and deed.  For example, the first article of the Manifesto states that we value well-crafted software over working software; yet there continues a significant debate on the topic of "good-enough software".  There is a large cohort of software developers who contend that well-crafted code is antithetical to time-to-market. 

The second article of the Manifesto is more interesting still.  It promotes the steady addition of value over simply responding to change.  What value does this refer to?  It refers both to the value of the software's function, and the value of it's structure.  That is, we as craftsman, will continue to steadily improve both the structure and function of the software, rather than simply responding to change.  This kind of responsible behavior is refuted daily by the actions of developers who release changes that damage both structure and function.  If you doubt that this happens, consider this video of bad code that I posted a few months ago.  Believe it or not, this is deployed production code.

Engineering vs. Craftsmanship.
Is craftsmanship antithetical to engineering?  Harvey suggests this possibility based on some of the statements in Pete McBreen's classic book Software Craftsmanship in which he derides some of the more egregious, high-ceremony and high-documentation practices associated with Software Engineering.  Harvey suggests that this may give "permission" to budding software craftsmen to ignore the good software engineering work that has been done over the decades. 

I agree that this would be a bad thing.  We don't want anyone in the Software Craftsmanship community to dismiss Software Engineering out of hand.  The problem I have with Harvey's  suggestion, however,  is that none of the leaders in the Software Craftsmanship movement espouse the view that the history of Software Engineering is worthless.  Indeed, quite the opposite is true.  Software Craftsmen see themselves as Software Engineers.  That does not mean we accept all of the Software Engineering dogma that has accumulated over the decades.  It also doesn't mean that we reject it.  It does mean that we learn it.

The Software Craftsmanship community is deeply committed to learning the lessons of the past.  That means studying the things we did right, and the things we did wrong.  Software Craftsmen immerse themselves in their craft.  We continue to read the old books by DeMarco, Yourdon, Parnas, Dijkstra, Hoare, Weinberg, and their brethren.  We study at the feet of the old masters so that we can learn how to be the next masters. 

It is true that we have currently tabled some of the older practices that have been associated with Software Engineering; but we do not disrespect those practices, nor the people who at one time proposed and adopted them.  They were pioneers who led the way and who, in some cases, showed us the paths to avoid.

The Craftsman Connotation
Harvey advises us to take care with the metaphors we choose.  He makes the point that terms like craft, dojo, kata, apprentice, master etc., can have negative connotations.  The word "craft" for example, may bring to mind the kind of quality one experiences at a flea-market or a craft fair.  The martial-arts terms that are sometimes common in craftsmanship circles may bring to mind the notion of the "omnipotent loner" like Bruce Lee, or Neo.  The terms "Master", "Journeyman", and "Apprentice" may bring to mind the secretive guilds of the middle ages with all their ritual, mysticism, and intrigue. 

I think this is a legitimate concern.  I also think it's easily dealt with.  The strategy I've been using is "guilt by association".  When I talk about Software Craftsmanship, I also talk about Software Professionalism.  I use the terms interchangeably in order to enforce the association in my listeners' (and readers') minds.  When I talk about dojo's and kata's, it is always in the connotation of "practice'.  I use the terms together so that there is no doubt about what the terms actually mean.

Harvey is right in that we don't want to create a "secret language".  There is nothing wrong with the memes we've chosen to communicate amongst ourselves; but we have to be careful to make sure we associate those memes with concepts like professionalism, practice, and seniority that our customers and employers understand and appreciate.   We want these people's support.  We want them to believe and trust in the values that we espouse.  We will not accomplish that by disrespecting the metaphors that they depend upon.