Software Craftsmanship

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.)

Post to Twitter Post to Plurk Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to MySpace Post to Ping.fm Post to Reddit Post to StumbleUpon

Comments (4) to “Software Craftsmanship”

  1. Mostly, I agree with you. However: you placed the phrase “Certification does not work” in bold, and did so without citing a reference or any history to support what you seem to feel is a very important point.

    In fact, certification does work, at least in engineering disciplines. In civil engineering, for example, a P.E. indicates mastery and is taken as such by both the law and by people looking to hire an engineer. It may not work in the software industry *as currently practiced*; I really don’t know, as I haven’t seen any data one way or the other.

    Do you have data you’d be willing to publish on this topic?

  2. Jerry, certification does not work to reassure the customer that they’ll get quality work. It doesn’t do so for P.E. licenses, for tradesman licenses, or for professional licenses such as held by doctors and lawyers. People still get crappy work.

    This is the point I was planning to make, but the preamble became an article in its own right. I’ll write more on this in a day or two.

  3. [...] were inevitable, of course, and came from Jason Gorman, Dave Hoover, Ade Oshineye, and George Dinwiddie, among [...]

  4. [...] Effective software development « Software Craftsmanship [...]

Post a Comment
*Required
*Required (Never published)