"Engineering means basing your work on scientific research. However, it does not mean basing your work exclusively on scientific research. Some of the highest-skilled professions are a mixture of scientific research and traditional craft."

Opening Statement

Twelve years ago, four remarkable guys -- Bruce Anderson, Norm Kerth, Dave West, and Ken Auer -- conducted a remarkable workshop at the OOPSLA conference in Vancouver: "Software as a Studio Discipline." You may or may not have heard about any of these four, but you definitely have heard of the outcome of another Bruce Anderson workshop titled "Towards a Software Architecture Handbook" at OOPSLA 1990. The book Design Patterns, published three years later, was envisioned there and has become one of the most influential computer books published to date.

The 1998 workshop was officially focused on teaching, but reading the call for participation today makes it look like the starting point of another movement. So let's go back more than a decade and look at an excerpt of the OOPSLA 1998 workshop program:

Think about the building or rebuilding [of] the Statue of Liberty, or producing a music record, [or] creating a major motion film. Here there is a careful blend of artistry and discipline. It includes the business of art, team building, mutual respect, managing your ego, putting your work on for exhibition, blending with other artists and other media, industry standards, tool/instrument mastery/maintenance, and so much more. It includes mastery and roles -- apprentice, journeyman, and master are found in some but not all fields -- why?... Why isn't software development thought of in the same way by the traditional teachers of our discipline?

Many have questioned whether software development has suffered at the hands of mathematically minded professors in the university setting who fail to address the larger picture and have therefore produced less than well-rounded individuals (geeks?) whose contribution to the reality of real-world software-related projects is often suspect....

Three years later, Canadian consultant Pete McBree, one of the participants of that workshop, coined the brand for these ideas in his book Software Craftsmanship. The book got some recognition, but its time did not seem to have come. The software world was then digesting the ideas of Extreme Programming (XP), discussing Model-Driven Development, and wondering how to deal with a prospering new language called Java. There was no discussion capacity left for meditating the foundations of our business.

Still, the seed had hit fruitful soil. In his Agile 2008 keynote address, Robert Martin, an Agile Manifesto coauthor, proposed adding a fifth line to the manifesto: "[We value] Craftsmanship over crap," a provocation he changed to "Craftsmanship over execution" a few days later.¹ The resulting discussion didn't lead to a change in the Agile Manifesto rather to a completely new Manifesto for Software Craftsmanship, published in 2009. This manifesto states:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software

Not only responding to change, but also steadily adding value

Not only individuals and interactions, but also a community of professionals

Not only customer collaboration, but also productive partnership

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.²

This consciously formulated extension to the Agile Manifesto addressed a growing uneasiness among many agilists: that with the tremendous success of Scrum, more and more people reduced the agile movement to the Scrum management practices. These core practices, they felt, don't address one of the major advances of agile as compared to the rapid application development (RAD) of the early 1990s: the ability to deliver high-quality code in a frequent and fast rhythm without spoiling the code base. Delivering working software every two to four weeks is only possible in the long term if you build up and tend a highly maintainable code base.

One of the major advantages of agile is increased transparency with regard to the problems and impediments encountered in projects, a transparency that invariably shows code does matter. In contrast to what marketing experts of tool and offshoring companies (as well as a significant share of the academic world) had been promoting, a good code base is the foundation for frequent delivery of valuable software, and a stable team of caring professionals in close alignment with the stakeholder's business goals is the foundation of a good code base.

The promoters of the software craftsmanship movement claim that programming is a skill that requires lifelong learning. They argue that you learn professional programming not only from a textbook, but also by collaborating with skilled peers. Of course, there are rules for good code, but building good code requires more than theoretical knowledge of these rules -- it requires tacit knowledge and experience. And this is where craft enters the scene: craftsmanship is the traditional means of teaching and transferring tacit knowledge and experience.

So is this a battle cry against software engineering? Some people think so. Personally, I believe this is an artificial conflict driven by too narrow an idea of what engineering really means. Engineering means basing your work on scientific research. However, it does not mean basing your work exclusively on scientific research. Some of the highest-skilled professions are a mixture of scientific research and traditional craft. Take surgeons as an example. No one would ever think that a great surgeon would restrict herself to planning surgeries while allowing the plans to be executed offshore by staff selected on the basis of minimum hourly rate. So the discussion is not that much about neglecting the engineering part of software development but about promoting those aspects that have been neglected to this point.

This issue of Cutter IT Journal aims at providing you with an overview of the different aspects of the current discussion of software craftsmanship. In our first article, Matthew Stuempfle and J. David Gibson ask, "What does it take to be a true craftsman?" Much like Rob Austin and Lee Devin in their book Artful Making, Stuempfle and Gibson ponder the craft of acting and the craft of software development and distill seven dimensions of a true craftsman that are common to both. While each element is critical, they conclude:

Each dimension alone, however, isn't enough to elevate a person to the state of a true craftsman. Craftsmen are and must be multidimensional. The interrelationships of the seven dimensions are differentiators that turn an actor or a software engineer into a true craftsman.

The counterpoint to this perspective in particular and software craftsmanship in general is taken by Cutter Fellow Ken Orr and Cutter Senior Consultant Paul Bassett. They consider craft a premature disciple of and counterconcept to engineering, which they deem the more mature approach. "After 60-plus years, it's high time our industry matured into an engineering discipline," they write, going on to suggest that perhaps the interest in software as craft is "really a rebellion against the current dictates of the software industry." Despite the authors' sympathy for developers in "Dilbert-like cubicles," they argue that turning software development into an engineering discipline is the way forward. "A key precondition to converting software from a craft to an engineering discipline is the existence of a universal modeling framework," they assert. The goal would be to "achieve a self-financing, hybrid IT infrastructure" in which a "central group consist[ing] of a few highly competent software engineers ... create and support standardized generic architectures and business models that are common to multiple systems and their various releases. They pay for themselves by supporting projects staffed with application programmers." Orr and Bassett's point of view is quite contrary to that of Stuempfle and Gibson, and you may agree to it or not. In any case their argument is quite common, and when discussing software craftsmanship, you have to face this challenge.

In our third article, Lawrence Fitzpatrick discusses not the basic ideas of craftsmanship but the pitfalls of its success. He reports on a custom software development team that "after successfully delivering a handful of targeted projects by adhering to craftsmanship principles, ... was given responsibility for all new software development" in a major regulatory agency. This led to explosive growth in the craftsman group, both hindering communication and subjecting it to cumbersome governance processes that threatened to crush the craftsman "lifestyle" that had produced such impressive results. The group fought back, adopting six core principles and five supporting tactics that enabled them to preserve craftsmanship and achieve "an unblemished delivery record over eight years," something few development teams can boast.

The development of a group not in quantity but in quality is what Stefan Roock writes about in our next article. He reports how he and his colleagues started off 10 years ago as XP enthusiasts, "reckless and uninformed," despite their years of education as software engineers at university. The result was increasing technical debt, with all its ugly consequences: slipping deadlines, increasing bug rates, unsatisfied customers. With experience and additional understanding, they eventually became informed: they had learned about the fundamentals of good design and how to apply it to professional software. Nevertheless, they still amassed technical debt in order to meet deadlines -- they still were reckless. To fight this, they decided to deliver only code they could be proud of, replacing the reckless attitude with a prudent one. Success did not follow immediately, but after a while "problems with deadlines started to vanish and the internal and external quality of the systems grew significantly." Roock identifies several core practices they adopted along the way, chief among them being a solid architecture vision; development practices such as test-driven development, pair programming, code katas, and coding dojos; and finally, decoupling and dependency management. Yet none of these practices would have been nearly as effective if they hadn't been guided by professional honor. As Roock concludes, "Everybody is responsible for what he (or she) does!"

In our next article, Cutter Senior Consultant Gil Broza extends the concept of software craftsmanship to include a business perspective:

Craftsmanship is attractive to developers and business alike; too much poor software is produced nowadays, and such software is in nobody's interest. However, neither is idealized software craftsmanship, which ignores business realities.

Broza calls for "contextual craftsmanship, which turns out the best product possible under the constraints of reality." To me as a German, this argument was surprising. Having a strong multicentury tradition of craftsmanship, most German craftsmen run their own businesses. Masters receive formal education in business administration, and those who don't learn the lesson are run out of business sooner or later, either by their customers or the tax authorities. In our tradition, it's not the craftsmen but the artists who practice "l'art pour l'art" and trade it for commercial success. Contextual craftsmanship is what a good share of our economy is built upon.

Our final article, by Michael Hughes, raises a topic that is rarely discussed in the current debate on software craftsmanship, although it becomes more and more crucial for the economic success of a software system -- the user experience design. There are two different roles competing for the "first right" of user interface design: user experience designers and user interface developers. While the former take a strong user perspective on the system to design the way the user experiences working with it, the latter deal more with the details of its implementation. This, Hughes notes, "can create organizational tension and competition that can impede efficient development and an optimized user experience." Like craftsmen, these two roles should appreciate their different skills and perspectives and work hand in hand to deliver the best product they can.

And so we conclude our issue on software craftsmanship. Now, is it the "new imperative," as Pete McBreen states in the subtitle of his 2003 book? That is still to be decided. However, software craftsmanship arose to fill a painful gap in our education and in the perception of our profession. If it is combined with engineering skills, it leads to more effective teams that deliver high-quality software at a steady pace. This is more than most managers dream of.

ENDNOTES

¹ Martin, Robert. "Quintessence: The Fifth Element for the Agile Manifesto." Object Mentor, 14 August 2008 (http://blog.objectmentor.com/articles/2008/08/14/quintessence-the-fifth-element-for-the-agile-manifesto).

² "Manifesto for Software Craftsmanship," 2009 (http://manifesto.softwarecraftsmanship.org).

ABOUT THE AUTHOR