Craftmanship And The Crevasse

Daniel Terhorst-North's recent blog post on software craftsmanship has unleashed a lot of blog discussions (which I summarize below, if you're interested). There's a lot in there, but one of his themes particularly resonated with me, hence this post.

Before I get to that, however, I just want to push one element off to the side. I've long felt that debates about metaphors for software development are tedious. While MetaphoricQuestioning has its place I'm fundamentally uninterested in whether software development is a craft, an art, a trade, or a dessert topping.

The point that matters to me isn't about the craftsmanship metaphor, but more a characteristic of the movement that seems to have sprung up in the last couple of years. From my outsider perspective, the primary force that's energized the software craftsmanship community is a reaction to the change in the agile movement. In the early days of the agile virus, the dominant strain was Extreme Programming, which has a lot to say about technical practices. Now the dominant agile strains are Scrum and Lean, which don't care very much about programming - and thus those people who primarily self-identify as programmers feel a large part of their life is no longer important in the agile world.

The software craftsmanship world, therefore, is place where programming can become front-and-central again. People can talk about testing, how to learn and use functional languages, principles of good design, etc. The management and analysis issues can then be left to the debilitated agile community. There's much I sympathize with here. I accept the DesignStaminaHypothesis which suggests that you need to pay attention to good technical practices if you want to develop software effectively. So a movement that gives these issues attention is important. But there also lies a danger, that by focusing too much on technical issues the craftsmanship movement will underplay the equally vital role of customer communication.

One thing I like so much about Kent's work is that there's a real balance between the relationship with the customer and the skills required to execute properly on our half the bargain. I remember him saying at the AgileManifestoMeeting that his primary aim with Extreme Programming was to heal the divide between software developers and their customers. This divide, which Dan and I characterized as the “yawning crevasse of doom“, is one the most important problems in software development.

A large part of the blame for the crevasse lies in organizational habits that are founded on the notion programmers and customers are such different creatures that they can't communicate (and shouldn't try). But many programmers gladly seem to go along with widening the crevasse too. Several years ago I was struck by Eric Evans's observation that as developers get more senior they tend to focus more on technical issues and don't tend to engage in understanding the domain they are working in. Domain-Driven Design is very much about trying to change that - although often it seems to get bogged down in discussions of topics such as how to use dependency injection on your repositories. (My own career has also suffered from this. As I've developed as a general software development pundit, I've no longer been able to work in domain modeling - even though that's always been my favorite part of software development.)

So just as Scrum and Lean exacerbate this problem by neglecting the technical skills, I fear craftsmanship in turn may make the crevasse worse by neglecting the relationship skills. My ideal of a programmer is someone who is not just skilled in the craft of programming, but is also energized by learning about the domain by communicating with domain experts so that she can participate in finding the best ways to get software to help make customers rock at what they do. Paraphrasing Dan, the software shouldn't be at the center of a programmer's world, instead a programmer should focus on the benefit that the software is supposed to deliver.

The blog chatter

(includes items posted in response to this entry.)

• Daniel Terhorst-North's original post
• Liz Keogh explains her discomfort with the software craftsmanship manifesto.
• Gil Zilberfeld draws a comparison between software craftsmanship and alt.net.
• Jason Gorman wants us to avoid getting hung up on labels
• Michael Feathers looks for more deliberate practice in our work.
• George Dinwiddie provides a physical example of why quality work is important to a customer, and how certification and licensing doesn't help.
• Daniel Terhorst-North expands and clarifies some his earlier points.
• Bob Martin says software craftsmanship is only about programmers tired of writing crap.
• Bob Martin thinks my fears are groundless (I hope he's right).