Software Craftsmanship is a set of values that extends the agile manifesto so that it considers quality in a more pronounced way. Instead of focusing solely on building the right thing it also includes aspects of building the thing right. In my opinion, you need both. You need to build the right thing so that stakeholders, customers and users get the value they need, but you also need to build the thing right – or else you end up with that dreaded big ball of mud with all its consequences like low maintainability, slow development, error-prone systems, low morale etc.
The Software Craftsmanship manifesto (fromhttp://manifesto.softwarecraftsmanship.org/, annotations by me):
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
[The code base should be easy to understand and maintain. As a developer I should be confident that I can do code changes and get feedback on any undesirable side-effects in a fast and automated way.]
Not only responding to change, but also steadily adding value
[This does not only mean steadily adding new features. It also means constantly improving the code base – keeping it clean and maintainable. You know it will rot if you don’t, right?]
Not only individuals and interactions, but also a community of professionals
[The heart of software craftsmanship is about sharing, mentoring and learning. Simply spreading the passion you have for high-quality code and constantly learning from other peoples experiences and knowledge.]
Not only customer collaboration, but also productive partnerships
[This means providing value to customers (and learning from customers) on all levels, e.g. helping customers understand a business problem. Software is more than code.]
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
Software Craftsmanship leans heavily on well-known XP practices like TDD and refactoring, so there is nothing new or magic in the toolbox. What is different is the ever present mindset and desire to self-improve and be more professional. The applying of the practices is pragmatic, e.g. you do a refactoring of the piece of code that is needing a new feature – you don’t make a refactoring for the sake of it. No religon. Pragmatism.
Sandro Mancuso’s book covers this topic in a very readable way based on many years of real experience. It covers Agile vs XP vs Craftsmanship, the new attitude, interviews, low morale, learning, driving technical change, pragmatism and more.
I really identified with this book and recommend it for everyone that that works with software development.
Thingsmatic 