I was asked recently to define “craftsmanship” in software development, and I thought this would make a great topic for discussion. You can obviously find a dictionary definition for craftsmanship, but much like with architecture, I think that when we attach the additional context of software development, craftsmanship introduces some important ideas about how individual contributors fit into a larger software development organization.
Software as Art
The concept of craftsmanship in general emphasizes the skills of individuals, and connotes high-quality, highly customized work. It is very much the antithesis of mass production.
This general understanding, when applied to software development, implies a very individualized experience — indeed, if you think about buying a work of art or even something like a piece of furniture, “craftsmanship” would imply that the product you’re buying is one-of-a-kind. Nobody, literally, has another item quite like the one you’re buying. For businesses commissioning custom software, there’s a nugget of truth here, of course — one of the reasons to write custom software is the presumption that your business requirements are different in some way from everybody else’s requirements, and your business demands the flexibility that comes with custom software.
Another key aspect of craftsmanship is the deep and broad skill set of the craftsman. Just as you’d expect a hand-crafted product to be almost entirely the result of one man’s work (to the extent that signing the work wouldn’t be unheard-of), so software craftsmanship emphasizes individual skill and accountability. And while craftsmanship doesn’t necessarily imply apprenticeship, a craftsman is certainly expected to be highly experienced and able to draw on years of work in the field in order to produce the sort of high-quality work that’s expected.
Business Implications
While high-quality, highly-customized software sounds very appealing from a business perspective, the deliberate pace and unyielding attention to detail we most often associate with craftsmanship is petrifying. Business software needs to move at the pace of business, after all, doesn’t it? I really believe that the implied slowness of craftsmanship acts as an impenetrable stigma against its adoption, which I think is largely unfortunate.
One of the key benefits of the higher-quality code produced by accomplished craftsmen is that less time is spent on an ongoing basis recovering from the sins of shoddy coding as these systems grow and evolve over time. High-quality code not only works better, it’s more maintainable, so that initial effort can pay real dividends over the life of a long-lived system. Where we sometimes talk about sloppy code as being high in technical debt, quality code can be seen as an asset for an organization.
Right now, software craftsmanship remains on the fringe of development practices, and thus tends to be favored in smaller shops, as well as in “green-field” projects much more so than in larger, more established environments. It remains to be seen whether it eventually transitions into mainstream use the way that Agile has, but I think a lot depends on the effective communication of the real benefits of craftsmanship, as well as on mature tactics to introduce and manage craftsmanship in the organization.
My Take
Craftsmanship is about individual contribution. It’s about taking pride in your work, and it’s about a relentless journey of improvement. The scope of these experiences is best-suited to small groups of developers who can help one another grow and hold each individual accountable to the group. This, all by itself, is a tall order. It’s not easy for anyone to expose himself to criticism, and that’s a huge prerequisite for this sort of culture to form. This sort of open sharing takes huge amounts of trust, and trust takes time to build.
Another critical motivator for a “craftsman-like” organization is the sense that the team is building something that’s going to last. When you think of hard goods built by craftsmen, you equate the higher quality to a longer lifespan — as a consumer, you may be willing to pay a premium for a product that will outlast a cheaper product because you know it’ll last a long, long time. In software, this understanding of quality has to be visible to the team as well as the customer, and the team needs to believe that this higher quality is valued. Few things are as demotivating for a developer as seeing a great body of code mangled by someone who doesn’t share the same capabilities or desire for quality.
It might seem at this point that I’m advocating an all-or-nothing strategy for software development, or that software craftsmen can exist only in small shops, but I don’t believe either of these is necessarily true. I believe that if craftsmanship is going to exist in a large organization, however, the organization needs to understand where it’s going to be applied and it must organize its teams to support craftsmanship in targeted areas. I think this prerequisite is well-suited to a component-based Enterprise Architecture, in which well-defined components or services are identified, invested in, maintained with care, and protected, and yes — this demands an enlightened and skilled application of Enterprise Architecture.
Craftsmanship isn’t a magic wand, or a buzzword, or a slogan. Craftsmanship takes hard work, and it demands commitment from organizations and developers. It’s not right for every organization, and it certainly isn’t right for all developers, but if you need software that stands the test of time, craftsmanship will pay dividends for the lifetime of that software.
