Measuring Craftsmanship


I’m on board with the Agile approach to software development and I have a strong history with process approaches to improvement (ISO-9000, CMM, CMMI, TSP, etc.). That said, I have always believed that the quality of the people doing the work is the biggest factor of success. The software estimation technique, COCOMO reveals this because “personnel attributes” dominates just about all COCOMO estimation models.

I think David Starr over on Elegant Code hits the right note in pointing out how this manifests itself in his post on Measuring Craftsmanship. His post starts with a distraction by arguing against the idea of measuring Agile maturity. I say distracting because I think it’s possible to agree with his message about the importance of craftsmanship no matter how you feel about the idea of creating an Agile Maturity Model.

The emphasis needs to always be on the people doing the work. In particular, I like his idea of “picking a guild” as a source for your skills criteria. Because of the way the software industry works, each organization might be its own guild, so I think it will be hard to agree upon the list of guilds and find a set of criteria most appropriate for each of them, but I think it is possible to create a map between certain practices and required skills.

For instance, if you are going to rely upon refactoring and emergent design, you better have strong design patterns skills. Same goes for tool usage. The practice of continuous integration requires build tool skills. Your team’s approach to software assurance also dictates the skills you need. If you rely heavily upon automated testing, then you need skills with automated testing tools and patterns that enable design for testability. If you rely more upon inspecition, mastering the skills of Spineliis Code Quality and Code Reading should be expected.

 

This entry was posted in Software craftsmanship and tagged , . Bookmark the permalink.

One Response to Measuring Craftsmanship

  1. Mr. Hericus says:

    I see the tools aspect that you are talking about a little differently. To me, tools (be they for Continuous Integration, Modeling, Automated Testing, Inspection, etc.) are those things that free you to focus on your true craft. Sure you need skills to handle the tools properly, but if you focus too much on learning everything about the tools and building your skills there, you’ll miss the real focus, which is what the craft is all about.

    The tools should make your life easier, not make the list of required skills longer.

Leave a Reply

Your email address will not be published. Required fields are marked *

Spam Protection by WP-SpamFree