In part two of my series on software craftsmanship I take a look at how Peter McBreen, in his book entitled Software Craftsmanship (McBreen, 2001), sets up software craftsmanship in opposition to software engineering. Actually he does say that "Software craftsmanship is not the opposite of software engineering or computer science. Rather, craftsmanship is a different tradition that happily coexists" (p. xvi). But the rest of the book undermines any claimed coexistence.

Defining Software Engineering

McBreen starts with the IEEE definition of software engineering:

Software engineering is the application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software

IEEE (1990)

And it is the "systematic, disciplined, quantifiable" aspect that McBreen doesn’t like.

The biggest problem with software engineering is the assumption that a systematic, disciplined, and quantifiable approach is the only possible approach. (p. 11)

But McBreen doesn’t stop there. He believes that software engineering is dumbing down development.

The "dumbing down" of programming – something that software engineering has been advocating for years. (p. 88)

The implicit promise of software engineering is that if we can just define a systematic, quantified process, anyone can be successful at software development. This idea is wrong. (p. 12)

Software engineering is aimed at "managing hoards of ‘average’ programmers working on large projects that continue for years" (p. 60 citing Stumm, 1993)

What Software Engineering is Good For

Because of these problems McBreen believes software engineering is appropriate for quite a limited range of projects: systems engineering and "good enough software".

Systems engineering projects that involve the development of new hardware and software are a natural fit for software engineering. … If your organisations developers large, shrink-wrapped consumer software applications and is good at making appropriate engineering trade-offs, you might be able to use the good enough software approach. … In all other cases you should be looking for alternatives to software engineering. (p. 8-9)

Good enough software is a logical extension of the ideas of software engineering. It represents the engineering trade-off between resources, schedule, features, and defects. … commercial shrink-wrapped applications like word processors and Web browsers need lots of features that must be developed quickly. Resources are constrained by the need to make a profit, so the engineering trade-off is made to shrink the schedule by spending less time removing known defects. The idea is that for some kinds of known defects, it is not economic to take the time to remove them. (p. 8 )

How Software Craftsmanship Fits In

So, the argument goes, if people are not working on either systems engineering and "good enough software" they should do software craftsmanship.

We need to focus our attention on how we nurture software developers so that they, too, can excel. As part of doing that, we need to question what we mean by systematic software development. (p. 13)

I see software development as a creative blend of art, science, and engineering, whose purpose is to deliver effective systems. The best way I have been able to describe this idea is by talking about software craftsmanship. The software craftsmanship metaphor allows developers to acknowledge all aspects of their craft – the artistic and aesthetic aspects as well as the measurable and mechanical aspects. (p. 28)

This book is a call to arms: We must insist that developers really know their craft before we trust them to create systems for us or with us. Whether you are a user, manager, or developer, it doesn’t make sense to trust an inexperienced software developer. This is why we focus on software craftsmanship rather than on software engineering. The best processes in the world will not save a project from failure if the people involved do not have the necessary skills to execute the process; conversely, really good developers can make any process work. (p. 35-36)

So, to paraphrase the above, software craftsmanship is a creative blend of art, science, and engineering, whose purpose is to deliver effective systems, conducted by experienced developers who really know their craft and, because they are experienced and skilled, don’t need a systematic, disciplined, and quantifiable approach. And it definitely isn’t software engineering.

But maybe Software Craftsmanship can be Software Engineering

Some people criticise McBreen (2001) for forcing readers to choose between software craftsmanship and software engineering. Hoover & Oshineye (2009), who are themselves strong advocates of software craftsmanship, say:

He [McBreen] makes the mistake of defining software craftsmanship in opposition to software engineering, and asking his readers to choose between them. We think that a craft model can be defined in a positive way that doesn’t exclude those people who feel that there’s something valuable in the attempt to build a discipline of software engineering.

Hoover & Oshineye (2009), Apprenticeship Patterns: Introduction

What I think about it all

If you accept the IEEE (1990) definition of software engineering then McBreen is probably right. Personally I think McBreen’s allergy to software engineering is a product of the time he wrote, 2001. The 1990s saw the rise of the Capability Maturity Model from the SEI of Carnegie Mellon University (see SEI: CMMI). CMM is an ultra-process oriented approach to development. One that I don’t subscribe to, so I’m with McBreen on that.

I also agree with McBreen that "really good developers can make any process work" but I think it depends on how you define "good". I have met developers who are good when working alone and a disaster as part of a team. I disagree with the claim that only really good developers can produce good software. David Anderson (2010) also challenges this assumption and gives an example where a little bit of process, i.e. the Kanban Method, made an under performing team world class. And given not everybody can "hire small teams of good developers", but just has to make do with what they’ve got, then Anderson’s approach offers considerable hope for the majority of organisation that can’t hire a "master".

For myself I use software engineering in a much looser sense than IEEE (1990) or McBreen (2001) do. And my type of software engineers meet McBreens definition of a craftsman. Perhaps that is because it is now 2012, not 2001, and in some ways software engineer is now just a job title. But I don’t equate a software engineer with a developer. Basically I use software engineer to contrast with what I call bedroom developers. In my view bedroom developers are people who can hack together stuff by themselves, often for themselves. In contrast software engineers, in my opinion, are people who can build software, as part of team, in the context of an organisation, for a large audience. And that requires discipline. McBreen talks about "trust" and to paraphrase him, I trust professional software engineers to deliver effective systems for me. I do not trust the undisciplined hobbyist hackers from the bedroom to do this.

In subsequent posts in this series I’ll look at other definitions of software craftsmanship. Next up is the view that software craftsmanship is not writing crap.

References

Anderson, D. (2010). Kanban: Successful Evolutionary Change for your Technology Business. Blue Hole Press.

Hoover, D. & Oshineye, A. (2009). Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly. [Available on-line http://ofps.oreilly.com/titles/9780596518387/]