the manifesto for software craftsmanship

So as I’m sitting here thumbing through my InfoQ feed on Google Reader, I come across the following posting: Software Craftsmanship Manifesto: A Call to Arms. It seems that a group of “programming patriots” has struck again (see the Manifesto for Agile Software Development - circa 2001), complete with a “founding document” look and feel. Clicking through the source link, one finds the following:

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.

You can’t even imagine my excitement in reading this. This statement of values is something that I have been trying to get across without having the needed words for quite some time.

The motivation, says the InfoQ article, is right on target:

The members of the manifesto group answered two key questions: “How will it help solve the problems of crap code?” and “What will motivate “The developer just churning out code” to become a craftsman?” - the distinction is between the developer who is just getting it done vs the one getting it done right.

I have felt for a long time that the elements of craftsmanship are something sorely missing from our field. We, as programmers, are often so consumed with getting the job done that we do often neglect getting it done right. In our haste to move on to the next exciting project and/or technology, we neglect the tenets of simple design, test-driven development, merciless refactoring, clean code, etc. We’re often quite satisfied with the “hacky solution here” and the “quick and dirty solution there.”

Quite frankly, I’ve had enough of that. I’m not satisfied when the contractor building my house cuts corners. I’m quite irritable when my mechanic does a less than thorough job with my car. Why should I expect my clients to settle for software built like that?

So, to make this a practical rant, I thought I’d share a couple of the things that we’re doing in our team to move us in the right direction:

1. First of all, we started a weekly “brown bag lunch/workshop,” inspired by Andy Hunt and Venkat Subramaniam’s discussion in Practices of an Agile Developer.

2. Second, we selected books to read as a team that will point us in the right direction. Our first two titles were The Pragmatic Programmer: From Journeyman to Master (see, there’s craftsmanship right away!) and Clean Code: A Handbook of Agile Software Craftsmanship (sense a pattern yet?).

3. Third, we make a point of our weekly discussions to look at ways we can integrate the principles and practices that we’re learning into our daily work. An example: We’re working to integrate peer code review into our development process. The principles, patterns, and practices that we’re picking up from Clean Code will be informing us as we review code and look for possible improvements.

So, with that said, tonight I became a signatory of the manifesto. Why don’t you join me and fight the fight against crappy code!