Software Craftsmanship

There’s been a lot of talk over the last few weeks about Software Craftsmanship — triggered by the Dan North’s recent criticism of the manifesto. Martin Fowler seems to think the movement is partly a reaction to the ‘de-technicalisation’ of Agile, while Bob Martin responds with “we just don’t like writing crap”.

I would probably put myself in the Craftsman camp. I see a couple of benefits to the concept:

• First & foremost, it encourages programmers to take pride in their work. When people take pride in their work it results in a happier, more skilled, more motivated set of professionals churning out higher-quality work. Note that this is not the same as gold-plating, which is the result of poor product/project management, not enthusiastic programmers.
• I think utilitarian assessments of customer value like “if it does the job, it doesn’t matter what it looks like” are a fairly narrow-minded view engendered by too long spent working on enterprise software. Implementing dry feature checklists to an abstract definition of ‘business value’ (a concept that is notoriously bad at measuring the returns of good software that users actually want to use) can skew your concept of inherent value (it’s happened to me before). In other scenarios (eg the iOS App Store), developers that think utility is enough tend not to do so well.
• I’m extremely skeptical that ugly code is completely uncorrelated to customer-visible ‘quality’.
• I generally agree with Bob Martin that focusing on code quality and the technical side of software development isn’t mutually exclusive with doing a good job on the customer interaction side - I would actually go further and say it will improve. Quality begets quality. A team with (even one) disillusioned developer churning out poorly structured code is unlikely to somehow produce customer-delighting software - see Bad Apple Syndrome.