Dan North has created a bit of a stir with his declaration that programming is not a craft. Liz Keogh has agreed with him.  The funny thing is that most of what they have to say is not about programming, but about the Manifesto for Software Craftsmanship.  Well, writing is a craft, also, and I’ll agree with Dan that this manifesto is not “a call-to-arms, feisty, opinionated, brash and everything that a good manifesto should be.”  It never grabbed me the way the Agile Manifesto did.  Dave Hoover has taken this challenge as a call to improve the software craftsmanship manifesto.

I didn’t “sign” the Manifesto for Software Craftsmanship because I thought it was particularly well written, though.  I signed it because I support the intent (as I perceive it, and which Ade Oshineye defends) behind that manifesto.  Writing software is a craft, and there are far too many people who don’t treat it that way.

Some of the people who treat software as something other than a craft go the route that Dan North fears, indulging in adding baroque complexity for their own sense of aesthetics.  That, despite Dan’s suggestion, is not craft, but art.

Yes, a craft implies imbuing a utilitarian product with a certain beauty, but that beauty is not necessarily either “fancy decorative stuff” or separate from the value of the product.  In Dan’s example of a cathedral, the ornamentation and grace is part of the functional aspect of the product.  A cathedral is not merely a glorified hut to keep the rain off.  It is designed to lift peoples’ spirit and guide them to think of things larger and grander than their everyday life.  This is appropriate design for the purpose, and part of “amazing your customers.”

The utilitarian beauty of a craftsman is not all cathedrals, however.  Look at the design of Shaker furniture.  It is elegant in its spareness and utility.  It is designed to delight the user without any ornamentation.  This is another way that craft is expressed.

At the other extreme are the programmers who develop systems which result in “the clanking of information as it rattles from one poorly-implemented system to another, through ill-conceived interfaces.”  These are the poorly-skilled (in practice, at least) programmers for whom the Software Craftsmanship movement is intended to help.  In many cases, this is a result of a lack of knowledge, a lack of practice, or both.

In the end of his rambling post, it appears that Dan’s real concern is providing reassurance that systems “were being built by master craftsmen rather than day jobbers.”  It’s the certification issue, again.  Certification does not work.

Certification does not provide such reassurance.  I think a better approach is to increase the general level and availability of craftsmanship in the software industry.  True craftsmanship is often not immediately visible to the customer, but the lack of it becomes visible when systems take a long time to build or modify, and when they exhibit a lot of quirks in usage.

My expectation is that, while programmers may seek to be craftsmen for their own sense of pride, customers will seek craftsmen programmers for the long-term financial rewards.  That’s where quality pays.

(Note: the use of the word “craftsman” is not a reference to any gender.)