Playwell

A discussion today on Twitter (kind of an oxymoron, that) about craftsmanship, reminded me of this essay I wrote long ago. It was originally published in Visual Studio Magazine in 2003. Some of the stuff I tsk, tsk over is being successfully addressed by agile and post-agile thinking, but the nature and role of craftsmanship remains unchanged.

—-

Programmers are craftsmen and craftswomen. They are commonly thought—and frequently titled—engineers, but few working programmers “engineer” things. Most  build software. They craft it into existence.

I define craft the way the word was used hundreds of years ago, when a craftsman was a skilled expert who produced practical objects, and whose work was unique and highly valued. Only the wealthy could afford such finely made, custom objects. The Industrial Revolution elevated the engineer over the craftsman, and craft came to mean anything from sweatshop assembly to decoupage. The great engines of the Industrial Revolution were made of metal, powered by steam and electricity, and designed by engineers. The revolution’s ultimate fruit—mass production—was the antithesis of craft. Everyone could afford mass-produced items. Western society traded custom-fitting and superb quality for adequate quality and egalitarian access (an excellent trade, I believe).

The assembly-line worker was neither engineer nor craftsman. Although literate, he wasn’t well-educated, and his job required only minor training. Sadly, the term “craft” was often associated with him, because he was the proximate creator of goods, and industrialization devalued the term. The craftsman’s reputation waned, and many preindustrial crafts have disappeared.

The engineer was the educated, trained expert who designed the manufacturing processes: the “engines” of industrialization. The engineer was clearly the most highly skilled person in the industrial age hierarchy. But engineers don’t actually build things. They solve complex and demanding technical problems necessary to building things but leave the actual creation to others. Engineers don’t build bridges; ironworkers do. Engineers don’t build automobiles; assembly line workers do. Engineers don’t build software; programmers do.

The industrial age is over, and we’re in the information age now. Manufacturing still exists, but even a business sage as trusted as Peter Drucker says it’s no longer possible to differentiate your company by way of manufacturing. Even manufacturing companies don’t make money by creating things, but by using software to make sure they manufacture the right things, in the right quantities, at the right times.

The shift from steel to bits has been rapid enough to generate ample confusion about our modern roles. The most important builders today are programmers, and it’s only natural that they’d adopt a title such as “engineer” to reflect this status. Language influences our perceptions and our values so using the wrong job title can derail an entire profession. Programmers’ chief responsibility is creating product, not solving technical problems. Having chosen the wrong job description, our profession finds itself suffering from a profound misunderstanding of its role. The result is failed software products, executives who are terrified of programmers, costly tech support and training, and a fruitless quest for a cure in ever more obscure engineering processes.

Although programmers solve tough technical problems all the time, software isn’t mass-produced, and it’s definitely not “manufactured” by interchangeable, marginally trained assembly-line workers. But software’s unique nature was unforeseen by any industrial age thinkers. Software can be copied and distributed without limit, so it shares the egalitarian access of industrialization, but unlike washing machines or cloth, it can be custom-morphed and configured for each installation. This “mass-customization” is a new, purely information-age concept that was neither technically nor economically feasible in the industrial age. It resurrects the notion of craft in the preindustrial sense of requiring experts’ talent, training, and skill, focused solely on a practical outcome.

Engineers primarily devise manufacturing solutions and solve technical problems. They’re rarely responsible for the actual construction of things. For example, a structural engineer devises solutions that allow a building to stand firm, but she lives in a world of paper and mathematical models and won’t lift a finger to weld steel or pour concrete. It behooves the engineer to try numerous solutions, exploring dusty corners of the problem to find opportunities for improvement. It behooves the craftsman to stay on well-known ground and to avoid costly experimentation. The engineer works on paper prior to construction, and the craftsman builds the end product. The engineer throws away paper; the craftsman throws away time and money. Both are prized for devising creative solutions to difficult technical problems, but craftsmen are most highly prized for constructing sound artifacts quickly, efficiently, and expertly, with a minimum of waste and a maximum of predictability.

I asked a friend who supervises building construction how he defines “craft.” He said it’s characterized by a proclivity to think things through, to understand the problem fully, to have the necessary experience in the job, to get results with top-notch quality, and to meet the customer’s expectations. This last point is important, because it differentiates art from craft.

A programmer friend, describing how he is a craftsman, asserted that he works the way a sculptor or painter does. He was incorrect, but understandably so, because it’s easy to confuse craft with artistry. He was referring to the demanding techniques of construction, and the pride and personal satisfaction he gets from his efforts. But art rarely has a practical purpose the way that craft and virtually all software does. It’s an artist’s privilege to change the context, form, and meaning of her creation, but the external requirements placed on software can’t be changed simply because the programmer wishes it so, and there’s little room for the artist’s whims or wanderings in the programmer’s cubicle. Art can include craft, but the reverse isn’t true. Comparing a programmer’s work to an artist’s is a compliment, not a literal analogy. An essential ingredient in professional craftsmanship is knowing how to work within the box—a box that’s always defined precisely by detailed drawings and plans that an architect created and engineers vetted.

My late father was an electrician who knew his trade inside and out.  He was bright, though not formally educated. He would confound his supervisors occasionally when first arriving at a new construction site, because instead of diving into the wiring, he would look, and measure, and mostly stand and think. He was calculating mentally how to accomplish the wiring with the greatest efficiency of effort and material. One of his bosses said, “When Bob Cooper was just standing there thinking, he was being the most productive.” He was clever, creative, and proud, but he always respected that a great result did not, could not, include any redefinition of the problem. He knew that good craftsmanship meant fabricating the best component for the whole solution. He was not free to redefine the problem, but his efforts had to be a coherent part of a well-planned whole, a design. Above all, my father was a craftsman.

Commercial programming is clearly a craft. Unfortunately, the failure of our profession to recognize this has allowed two profound problems to grow. First, programmers almost never work to a plan. All craftsmen exercise their skill within a context well defined by detailed, written descriptions of the desired ultimate form. These plans are typically devised and drawn by an architect, a role rare in the software world. Architectural plans are necessary to ensure that the work of multiple craftsmen dovetail together, and that it meets the buyer’s expectations. Most contemporary programmers work only from a list of features and a deadline.

Second, programmers are almost never supervised. Craft is by nature detail-focused and deeply involving. Good craftsmen regularly work in a state of flow, so they must depend on others to make sure that their efforts merge with those of other craftsmen. The supervisors aren’t there to keep craftsman from dodging work, but to ensure that the big picture is tended to. A well-crafted building, for example, is more than an assemblage of sturdy walls; the walls must connect properly. The craftsmen can do this, but they rely on someone else to coordinate their work.

Many programmers are expressing dissatisfaction in their practice and I’m heartened by their resultant quest for ways to improve it. Extreme programming reflects a quest for supervision (from a pair programming partner) and for a plan (from the customer). Visual object-modeling tools such as Unified Modeling Language (UML) similarly seek to plan and supervise programming by applying powerful engineering tools. Although these can’t be viable substitutes, they indicate a strong awareness of the problem.

Our misuse of language and titles gives programmers license to let practical construction imperatives slip by and to focus instead on in vitro problem solving. Examining software in the light of the confusion between craft and engineering brings previously obscured causes of many common problems and their solutions to light. Unlike engineers, craftsmen create commercial software, and they need design plans and supervision to yield the results expected of them. Good engineers love their work because they love to solve difficult problems. Good craftsmen love their work because they love to make things. Good programmers must do both, but they’re judged ultimately on the efficacy of what they make, not on the cleverness with which they make it.