In part five of my series on software craftsmanship I look at the definition of software craftsmanship presented in the book by Hoover and Oshineye (2009). Their definition is wrapped around the concepts of community and values. Nice embracing terms but what does that mean for software craftsmen?

The Definition

Hoover and Oshineye (2009) were dissatisfied with dictionary definitions because they found them to be circular.

The dictionary definitions for simple words like craft, craftsmanship, apprentice, journeyman, and master are insufficient for our needs in this book. They are often circular (with craft being defined in terms of the skill a craftsman possesses, a craftsman being defined as someone who exhibits craftsmanship, and craftsmanship being defined as the quality that binds together the craftsmen working in the craft tradition), seldom grounded in the history of the guild system in specific countries, and often generalized to describe anything that is skillfully constructed. In short, these definitions fail to exclude anything and so include everything.

Hoover & Oshineye (2009), Apprenticeship Patterns: Introduction

Having abandoned common usage, Hoover & Oshineye (2009) then offer this definition instead:

When we use the phrase software craftsmanship we’re talking about a community of practice united and defined by overlapping values

Hoover & Oshineye (2009), Apprenticeship Patterns: Introduction

Presumably a community of software practice.

Community

Actually I find the Hoover and Oshineye (2009) definition quite odd. They define a craftsman in terms of the community he/she belongs to rather than what the person does or can do.

The "community" aspect seems to be a big deal to the software craftsmanship movement. So big that one of the values from the Manifesto for Software Craftsmanship is "Not only individuals and interactions, but also a community of professionals". But at least in this variation the individual is acknowledged.

I suspect that the real point is about identity. Essentially, with this definition, if I identify with the software craftsmanship movement then I am a software craftsman. Nifty.

What Happened to Skill?

There is no mention of skill in the Hoover and Oshineye (2009) definition, although skill is mentioned in the book. They do see skill as an essential ingredient of the software craft. And they bundle skill into the contrast between the software craft and software engineering.

Software development is a craft precisely because we don’t understand it well enough to make it a codified discipline like science or engineering. Despite the best efforts of groups like the Software Engineering Institute and the Agile Alliance, our field is still one where individual skill is often the most significant determining factor in a project’s success. When we use the word skill, we don’t just mean how much computer science you know or the effectiveness of your development process or how much experience you have. We mean the union of all the things it takes to deliver working software.

Hoover & Oshineye (2009), Apprenticeship Patterns: Conclusion

I am twisting the intent somewhat but I don’t like two things about that statement. Firstly, the implication is that practitioners in software rely on skill and other professional practitioners don’t.

Secondly, I absolutely disagree with the statement that "individual skill is often the most significant determining factor in a project’s success". This is only true if there is only a single person on the project. As soon as the team grows I believe it is the synergy between the team members that is paramount over individual skill. A team of stars is not necessarily a star team.

Values

Like community, values are also big. What distinguishes the software craftsmen, in the Hoover and Oshineye (2009) definition, from programmers in general are the overlapping values. So what are the values?

Manifesto for Software Craftsmanship

There is a Manifesto for Software Craftsmanship and it lists four values.

As aspiring Software Craftsmen we are raising the bar of professional
software development by practicing it and helping others learn the
craft. Through this work we have come to value:

Not only working software,

but also well-crafted software

Not only responding to change,

but also steadily adding value

Not only individuals and interactions,

but also a community of professionals

Not only customer collaboration,

but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

© 2009, the undersigned.
this statement may be freely copied in any form,
but only in its entirety through this notice.

The Manifesto for Software Craftsmanship is clearly intended to embellish the values of the older Agile Manifesto. I’m not convinced the Agile Manifesto needs embellishing but the additions are ok.

I do find it odd that three of the four values are about doing the work but the community one is not, and does stand out a bit as a consequence.

Apprentice Values

Hoover and Oshineye (2009, Apprenticeship Patterns: Introduction) have a long list of values separate from those of the Manifesto for Software Craftsmanship. I agree with many of these values and they form part of my own belief system. For the record I believe in adapting to feedback, being pragmatic, experimentation, taking control of and responsibility for my own destiny, inclusiveness, and the value of situated learning. But I have problems with some the other stated values.

I fundamentally disagree with the premise that with effort you can develop talent. Effort can improve skills but I agree with Buckingham and Coffman (2001) that a talent is "a recurring pattern of thought, feeling or behavior that can be productively applied". People have it – and demonstrate it regularly – or they don’t. My experience managing and teaching programmers leads me to the belief that some people have the talent necessary to be an effective software developer and some don’t. Effort can help people get better within the constraints of their talent but really you’re wasting your time expending effort on something you don’t have a talent for. And you’re also doing other people a disservice by encouraging them to bolster an area where they lack the intrinsic talent. John Daniels: Inside the mind of a Craftsman makes a similar argument specifically in the context of software craftsmanship, i.e. that some things that define a craftsman can’t be learnt.

I like the stated commitment to inclusiveness. It will be interesting to see if this pans out in practice. Dave Harvey, for example, sees a danger in the software craftsmanship movement of "guildification", which is the anti-thesis of inclusiveness.

I’m indifferent to the idea that "it is better to share what we know than to create scarcity by hoarding it". I’m grateful to the Free and Open Source Software communities but I don’t begrudge people trying to make a living from the product of their creativity, time and energy.

I’m ambivalent on the "focus on individuals rather than groups". Writing a book on how to improve individual skills is fine; no argument there, seems a good idea. But I don’t accept other parts of the stated value.

A focus on individuals rather than groups. This is not a movement with leaders and followers. Instead, we are a group of people who want to improve our skills and have discovered that debate, dissent, and disagreement rather than blind deference to self-proclaimed authority are the way to get there. We believe that we are all on the same journey and that the change we seek is in ourselves, not the world. This is why this book doesn’t focus on how to fix your team, but rather on ways to improve your own skills.

Hoover & Oshineye (2009, Apprenticeship Patterns: Introduction)

Actually I do think the software craftsmanship movement is trying to change the world; they don’t want to be forced to write crap software after all. I also think there are obvious leaders in the movement: the authors of the books, the people who organise seminars, etc.

Regarding being skill-centric versus process-centric although I agree that "more important to be highly skilled than to be using the ‘right’ process" I do believe a team needs an appropriate process for their context.

What I make of it all

Community membership is clearly important to the software craftsmanship movement, or at least some of the members, and to Hoover and Oshineye specifically.

Most of the values from both the Manifesto for Software Craftsmanship and Hoover and Oshineye (2009) look good to me. I don’t agree with all of them but that isn’t a threat to my membership of the software craftsmanship community as I only have to "overlap" to join the party.

Ultimately I think it is self-identify with the software craftsmanship community that is the defining factor for Hoover and Oshineye (2009). My problem with this is that this self identification does not make the community member a better software developer. Maybe that doesn’t matter to Hoover and Oshineye. It does matter to me.

In subsequent posts I’ll look at other definitions of software craftsmanship.

References

Agile Manifesto

Buckingham, M., & Coffman, C. (2001). First, Break All the Rules: What the World’s Greatest Managers Do Differently. Simon & Schuster.

Dave Harvey

Hoover, D. & Oshineye, A. (2009). Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly. [Available on-line http://ofps.oreilly.com/titles/9780596518387/]

John Daniels: Inside the mind of a Craftsman

Manifesto for Software Craftsmanship