On craftsmanship

Well, I certainly didn’t expect that kind of interest in my last post. In the past I’ve tended to have a few hundred people reading my infrequent mumblings. In the last few days nearly 20,000 people have popped by according to my site statistics, leaving nearly 150 comments. Crikey!

The overriding message I got was that without providing evidence and concrete examples one way or the other, it was all a lot of noise about terminology. One of my intentions this year is to expand on some of the implications of Deliberate Discovery, which fit the bill nicely in illustrating programming-as-a-trade, so my next article is the start of a series of posts along that vein. I’ll let the evidence speak for itself and you can draw your own conclusions.

I’ve been very grateful for the feedback and comments, and the dialogue on Twitter. I didn’t spend as long as I might have editing and cleaning up the article, largely because I’d been tinkering with it since before Christmas, rewritten it twice, and decided it was better to publish early and respond iteratively to feedback. Typical - go out without your best underwear and you get run over by a bus.

The critical feedback generally fell into the following categories:

• How dare you! You obviously know nothing of which you speak. (Well, you decide)
• You obviously don’t / have never / no longer code / care about programming. (Not true)
• You’re using a pretty crappy definition of “craft” to put forward a bogus argument. Here’s mine / Wikipedia’s / my dad’s / a selective entry from a dictionary’s. (That’s not the point)
• You shouldn’t/can’t compare programming to building / plumbing / fine art / martial arts. (See “On metaphors” below)
• I’m angry and important so I’m just going to poke you with a stick rather than do any actual thinking. (Meh)
• Where’s your evidence? I say “craft,” you say “trade,” show me evidence it’s a trade. (My next few posts)

It seems this is a sensitive subject area so I’ll be editing more carefully from now on to try to pre-empt some of the more obvious critiques I left myself open to in the previous post.

On value ¶

If I gave the impression that I wanted the cheapest or quickest cobbled-together solution then I certainly didn’t mean to. I want the best value software, something that’s fit for purpose in this specific context, to solve this specific need.

I’m not going to mandate test-driving anything (which is a huge about-face from what I was saying a year ago), unless it will help. Copy-and-paste is fine too. (Before you go all shouty at me again, hold off until I blog about the benefits of copy-and-paste, as it appears in a couple of patterns I’m calling Spike and Stabilize and Ginger Cake. You might be surprised.)

I expect a programmer to apply the appropriate amount of rigour, discipline and excellence to any situation. They should be as comfortable hacking together a disposable script as test-driving a complex business calculation or mathematical algorithm, and they should have a good idea - based on experience - of when to adopt each of these attitudes. This to me is simply good, professional workmanship. (More about this in my next article.)

On metaphors ¶

I shouldn’t have to point this out, but based on some of the feedback it seems I need to. Metaphor or analogy highlights a particular aspect of a situation. If I say something is as calm as a millpond, I don’t also mean to imply that it is wet and has lily leaves floating on it. (Yes I’m aware this is a simile rather than a metaphor.)

I used the example of jiu jitsu because I studied it long enough to qualify as an instructor so I know a bit about it. I remember the awe I felt when I witnessed the calm, grace, power and control of two black belts performing their nage-ne-kata - the same thing that I stumbled clumsily through from time to time - at a national competition one year. They got a standing ovation. It was beautiful. Programming is not a martial art.

I used the metaphor of negative space to illustrate that the point of programming isn’t the software - it’s the information flow or utility that the software enables. Programming is not fine art.

On certification ¶

I don’t agree with, support or condone in any way classroom- or course-based certification. It’s a ridiculous money-making charade. (Yes, Scrum Master certification, I’m looking at you.) An inexperienced bully of a manager with a certificate is still an inexperienced bully of a manager.

I was attempting to open up a debate on how we might possibly recognise another’s skill and experience if we don’t a priori know them. This isn’t just a theoretical debate, it’s central to good hiring - or engaging outside help.

I have a lot of regard for experience-based and evidence-based qualifications. The way Dr. Patricia Benner applied the Dreyfus model to nursing in the US, for instance, completely reinvigorated the service. The sheer amount of hard graft and knowledge that most MBA-holders I know put into their studies is testament to how hard they worked to get one (and that they didn’t even bother trying until they had enough experience to attempt it).

I guess I’m saying any qualification worth its salt should enable me to see a curve of, or at least differentiate between, people-who-can and people-who-can’t (rather than just showing people-who-paid). A common refrain was that our industry and technologies change so rapidly that there wasn’t a syllabus or set of course content that could be sensibly assessed. I think I agree with this.

Some of the suggestions that came back were:

• Look them up online! If they’re any good you should find evidence of that in terms of their own online output or other people’s testimonials. I really like this, especially nowadays, but the counter doesn’t hold: I might overlook some great-but-quiet individual if this becomes my core criteria.
• Have certification. See above
• Become (literally) a journeyman, where you rove from company to company, working for a roof over your head, building your reputation as you go. I love this idea but it takes some logistics.

Basically this debate is going to run and run. And I’m glad about that. It’s a really hard problem.

On open source ¶

I consider contributing to open source projects an admirable use of time and a good way to practise your programming. However the average quality of most OSS I’ve seen over the years is bloody shocking. It’s utility, however, is undeniable.

One of the most widely used pieces of OSS is the venerable JUnit. Ironically this was thrown together by two guys on a plane on their way to a conference, who had some time to kill on a long flight. Partly this was so one could learn Java and the other TDD. The fact that the two guys were Kent Beck and Erich Gamma demonstrates that a) two smart and pragmatic enough programmers can put together pretty much anything under any conditions in a few hours, and b) you can get enormous utility without having to rigorously test-drive everything. (Although in this case I understand they did use TDD - Thanks Martin Fowler for the corrections.)

As another example, Joe Walnes, my examplar of the incredibly-talented-and-mildly-amused kind of software craftsman (see On craftsmanship, below), had one of his many open source projects rejected by a code repository’s review panel because it was “too simple - there was no point making it into a library.” Turns out it proved quite popular.

Open source software is as variable as any other software. The fact that it’s open source doesn’t say anything about its quality. It doesn’t mean it is not written or hosted by muppets (or genuinely talented people, for that matter - its open source-ness is simply an orthogonal concern). It’s most certainly not an “apprenticeship model,” but it’s a great way for people to read other people’s code (something we are really poor at as an industry), share knowledge and share the wealth of the utility of software.

On productivity ¶

I don’t have any scientifically-valid numbers for software productivity. I have a ton of informal, empirical evidence that a small group of talented individuals can be insanely productive, even compared with other teams of talented individuals. I’ve been fortunate enough to spend the last year living it (and it’s nearly killed me trying to keep up!).

The people I had in mind when I mentioned hundreds-of-times productivity have done things like standing up an entire soup-to-nuts electronic trading stack, from user-facing visualisations of real-time trading data through to fully-automated trading applications - in a few weeks. These are not standalone applications. They talk to (really complicated) financial exchanges, internal back office settlement and reporting systems, and all the usual corporate messaging infrastructure you would expect to see in a medium-sized firm. To use the words of Lewis Carroll, this is, of course, impossible. I’ll see your factor of 10 and raise you 100. It’s not common. In fact it is extremely unusual. But it does exist.

On programming as a trade ¶

Maybe I should have said “programming has far more in common with a trade than it does with a craft.” As with any analogy, of course there are aspects of craft in programming. There are also aspects of craft in plastering or electrical wiring. I can spot the effects of well-executed, skilful workmanship even if I’m not qualified to rate the work itself. There is just much more of an affinity with trade-ness. In the first instance software should be practical and fit for purpose. I want effective, I don’t want fancy.

The guy who fitted my satellite dish ran the cable incredibly carefully around door frames, through walls, hugging the tops of skirting boards - it was virtually invisible - because “I’ve got a wife too, mate.” My house is old. Many attempted refactorings haven’t worked out and have ended in at least partial rewrites. (Uh oh, a metaphor again. I know programming isn’t DIY.)

People want software because they want to solve a problem, not because they like the notion of software. Some software practitioners risk losing sight of that. That’s all.

On craftsmanship ¶

Some people really care about understanding “the Thing” that we do when we try to get computers to help us do stuff. They think about it, write about it and exhibit it in their work and their behaviour. (Thanks, Michael Feathers, for a thoughtful and insightful post.) These people are sometimes called craftsmen. I admire these people.

Some people self-identify as “rock stars” or “software craftsmen” in an unfortunate attempt to differentiate themselves from regular jobbing professionals, whom they regard as less talented or valuable than themselves. I don’t have much time for these people.

Some people are just really bloody good at writing software. They rarely blog, they don’t talk or write about software. They just love coding, solve difficult technical or domain problems in innovative and highly skilful ways in a fraction of the time of us regular mortals, to deliver real benefits. They learn a new tool or technology by using it in real work situations and figuring it out as they go. They think all this navel-gazing, posturing and chatter is a bit silly. I admire these people enormously! Some of them like to tease me. I’m ok with that.

Some people care so much about their profession (I’m using the term in a broad sense here to mean what-they-do-for-a-living) that they choose to help other less experienced practitioners in their field grow and develop their skills. They use their own time to write and freely publish material, or provide workshops or classes, out of a desire to raise the bar across the industry. They might go travelling, not only to develop their own skills but to share their skills and knowledge as they go. (And it makes a great odyssey story!) Sometimes they do this enough that people recognise it and call them out as software craftsmen. I think I admire these people most of all, because they are inspiring the next generation of programmers to think like that too.