The Craft of Programming
by Alan Cooper
June 2003 Issue
|
|
Alan Cooper
|
Discuss this opinion in the Talk to the Editors of Visual Studio Magazine forum on our Web site. Use this Locator+ code: VS0306SA_D
The opinions expressed in this editorial are those of the author and not necessarily the opinions of VSM.
|
Programmers are craftsmen and craftswomen. They are commonly thought of as—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 unique and highly valued practical objects that only the wealthy could afford. 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 they leave the actual creation to others. Engineers don't build bridges; ironworkers 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 you can no longer 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 a 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 evermore 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 he or 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.
Back to top
|