Programming is not not Programming

I used to call myself a "Software Craftsman" for nostalgic reasons, it made me feel good and connected to history - like to Conan's dad in the start of the movie, forging a sword - "We who found it are just men. Not gods. Not giants. Just men. The secret of steel has always carried with it a mystery. You must learn its riddle, Conan. You must learn its discipline." It was also a reaction against the idea that creativity could be commoditised or managed. This came from my investment in programming and the joy it has brought me, contrasted with the general neglect of quality and conceptual integrity I often felt in my field.

I was working on something related when reading Dan's Programming is not a Craft. I usually view the Internet as a snapshot of the recent past not worth dealing with too much on its own terms when it comes to its false sense of urgency. But this was well timed, having recently read The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise, by Nathan L. Ensmenger. The last chapters are about certification and turning programming into a proper profession first seemed like a really boring way to conclude a good book, but it was boring for all the right reasons. Earlier the book also discusses how computer science came into existence as an academic field, and the difference between the academic and professional worlds of programming, and the ongoing debate whereas it's science, engineering or an art, from the 50s and forward.

I used to have a very hazy image of what happened before I was born - this is quite normal - and instead I just got thrust into the middle of the home computing craze during the 80s. Exactly how the discovery of programming works is way out of scope here, but my point is that I was arrogant - "We live in the most important of times!", and few people had any respect or interest in the history of programming to share, except for the reverence for a few figures, usually from the early days of Unix, like RMS, who aren't representative. I would like to feel redundant recommending books like Tracy Kidder's The Soul of A New Machine, Gerald Weinberg's The Psychology of Computer Programming or Steven Levy's Hackers, but better safe than sorry.

We're still iterating over the definition of programming because it's an unresolved problem, and many people obviously feel that this somehow needs to be solved. I try to avoid entering metaphor-ridden discussions about what we do these days, as almost any field can be mapped on top of another with some imagination. If I remember correctly there's a part about this in the beginning of Code Complete where McConnell takes the metaphor idea and runs with it for a couple of entertaining pages. Programming can very well be considered a craft and it is one of the more useful metaphors - one reason this debate becomes so heated. But let's step back. The confusion again comes from why we're arguing about this - on one level this is a philosophical question, and that's more than fine. The inability to define what we do properly lies at the very core of why at least I love it. 

And if that's the case, what I think about the nuances of the metaphor is less important than the feeling that I can stand behind the actual movement - and that it's goals are both progressive and achievable - which seems somewhat unrealistic, as any definition of craftsmanship I can imagine would exclude most working programmers, as it requires some form of passion. My gut feel is that the Software Craftsmanship Manifesto is too obviously trying to repeat the success of the Agile Manifesto and miss the point that many people "going agile" seem to reflect on neither the left or the right side of it, and then it doesn't matter if they read the fine print ("that is, while we...") - and honestly, they may not even know, or care, that there's a manifesto. So they're also likely to miss the fact that the items on the left are basically the same in both manifestos - I first did when I skimmed it.

It's a bit painful to just ignore the Craftsmanship movement and not give it the time it may deserve. Part of it, like Ade and Dave Hoover's book Apprenticeship Patterns is definitely worth the time, especially if you fit the title. McBreen's book is also strongly recommended to balance an engineering (or manufacturing) centric worldview. But when discussing this, I think it helps to be clearer about the differences between what programming is to yourself, what it is in your work, what it is as community, what it is like in your dreams, and what it could be in reality. While also acknowledge that they cannot be separated. Symptoms of this can be seen if you read the comments and various responses to Dan's post (and follow up) or this debate in general. Some people debate the metaphor, and some the movement, if they are aware of it, and what its aims are or should be.

So what are we talking about again? Ah yes, "the customer is always right, and you're like a blacksmith?"

"Wrong".

 

I recommend Richard Gabriel's Better Science through Art [pdf] for further reading. Today's closing quote is from The Terminator, where Arnold and the clerk in the gun store are disagreeing about customer satisfaction.

hakan raberg, you can acces his weblog http://www.jroller.com/ghettoJedi/entry/programming_is_not_not_programming