What is Craftsmanship?

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

IMG_5891.jpg
Ladle (Photo credit: lambertpix)

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.

IMG_8296.jpg
(Photo credit: lambertpix)

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.

The politics of software

This fall, as healthcare.gov imploded before our eyes, we saw any number of self-proclaimed experts chime in on why it coughed, sputtered, and ground to a halt, and how, exactly, it might be fixed.  My guess is that the answer is more complicated than most of them let on, but I’ll bet there’s a healthy dose of politics mixed in with whatever technological, security, and requirements issues might have surfaced along the way.

IMG_6589.jpg

It seems somewhat counter-intuitive to talk about politics at all in the context of software development, of course.  One of the aspects of software that really appealed to me when I entered this field was that for most problems, there existed an actual correct answer, and there are no politics in algorithms.  Ah, to return to the halcyon days of simple problems and discrete solutions!

Today’s problems are more complicated than ever before, though.  Prodigious capabilities have bred complex systems and murky requirements under the best of circumstances, and no government project operates under the best of circumstances.  For those of you in private enterprise, you surely are aware of the struggles bred of competing interests and limited resources, but in a government setting, all those factors explode.  Funding is rarely connected directly to stakeholders, opinions are everywhere, and “deciders” are nowhere to be found.   Not to put too fine a point on this, but if we were to think of government-sponsored software as having been congealed rather than developed, we might be on the right track.  It’s actually a small miracle when these systems work at all, given the confluence of competing forces working to rip projects in seventeen directions at once.

Think back for a moment on the early days of Facebook or Twitter or any of the other massive applications that serve as today’s benchmarks of reliability.  They weren’t always so reliable, of course.  Twitter, in particular gave birth to a famous “fail whale” meme in 2009 as it sorted out its capacity and reliability issues.  To be clear, twitter operates on a huge scale, but all it’s doing is moving 140-character messages around — there isn’t a whole lot of business logic there, short of making sure that messages get to the right person.  It’s pretty easy to gloss over some of those growing pains, but virtually every large system has them.  In the case of healthcare.gov, the failures happened under the hot lights of opening night and amid opponents who wanted desperately to see the system fail, and fail hard.

If you work amid politics like this, I’d love to offer a simple solution, but sadly, I have none.  Instead, I’d urge a little empathy; walk a mile in the footprints of developers, project managers, analysts, and testers on projects like this before you criticize too vigorously.  I can assure you that if you think this was a failure with a simple cause, you’re mistaken.

Related articles

 

 

Enhanced by Zemanta