The idea of software craftsmanship seems to be gaining buzz recently. Just now, Martin Fowler has also written a blog post about it. The idea of software development as a craft vs. an engineering science isn’t at all new. The book by Pete McBreen, pictured, was published in 2001. (I’m not completely endorsing that book. But it is a part of the history.) The Wikipedia article has more history, so I’m not going to repeat that.
“Writing code is no longer the hard part of development; the hard part is figuring out what to write,” says McBreen.
I certainly agree with the second part of this statement, but I disagree that writing code is no longer hard. Uncle Bob Martin is with me on this. The industry abounds with laments about poor software quality, overly costly and failed projects. You can find plenty of explanations and proposals to improve this state of affairs. This discussion has been going on for decades without apparent progress in making software better. It seems to me there is a divide between the engineering and ‘best practices’ approach vs. the craftsmanship and evolutionary practices approach. The first approach starts from the assumption that software development can in principle be captured in the form of universal practices and standards, which if followed will lead to the best outcomes. It also seems to me that while historically this has not yet been the case (this can be argued, of course), nevertheless adherents cling to a hope that it still can be brought about or at least be more widely attempted.
The second approach, the craftsmanship movement, wants to reframe the problem as not a technical or research-oriented one, but as one of recognizing that human beings make software, and that only humans can grasp what it’s for. And recognizing that despite decades of attempts to make it easy for the users to write their own software, it really does take technical experts to do it well. The challenge then is to find those individuals who combine the specialization of a software analyst having the ability to enter into the minds and language games of the customers, with the specialization of the programmer, who knows how to write code. But this highly versatile type of person is a kind of rarity. And there is the practical problem of how to find and educate them. The craftsmanship adherents (I am one) are those who take it upon themselves to become proficient in all aspects of development. It’s not an easy task, but we have help in the form of many conferences that are centered on practitioners needs. We recognize the need to collaborate as paramount. And I think this is where the more traditional engineering approach falters, in that it presumes that people are a fungible resource, and that highly specialized individuals can be operated like cogs in a machine, which machine is the modern organization. It is only necessary to give people the proper training in areas where knowledge already exists and can be transmitted by educational institutions. Those people will communicate using traditional methods, specifically written documents. The limitations of these ideas is becoming more and more apparent to those developing software.
If good software depends on the availability of versatile and exceptional people, and such people are not readily available, what hope is there for widespread improvements in software outcomes? Not much. The only avenue for improving software by following the craftsmanship movement is to find ways to promote the recognition and education of exceptional people. But can exceptional developers ever become the norm? Probably not. Thus the reluctance to depend on exceptional individuals leads many organizations to emphasize standards of practices, in hopes that if people of average ability can be employed and made to conform to the rules, the outcomes will be good in proportion to that conformance. Is this faith well grounded is the hard question.
In conclusion then, it is not surprising to find widespread problems in software cost and quality, if achieving these goals takes exceptional people and such people are rare, or that professional standards of practice either are not well known or not actually used. It is also not surprising to find persistent arguments for standards of practices and training that would enable average workers to produce superlative results. So the debate seems to be whether to find and encourage exceptional developers, or to research and promote standards of practice. Why not do both? Are they really that antithetical? I am not sure, but it is clear that the understanding of human beings is quite different in each. And I believe that that difference lies behind much of the strident arguments.