This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: Bliki: CraftmanshipAndTheCrevasse
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
Dan 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.
Dan North
(aka tastapod)
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.
Previous Topic
