Software Craftsmanship - The New Imperative
the 12th annual Jolt Product Excellence and Productivity Awards the book won
The book is now published and is available from Amazon
and local bookstores. A Japanese translation is now available from amazon.co.jp,
thanks to the hard work of Masaaki Murakami (who also translated The
Pragmatic Programmer into Japanese).
Software Craftsmanship is a metaphor that can radically transform
the way that we create and deliver software systems, with implications for the
way we develop software, manage teams and deliver value to the users.
One of the classical problems in Software Engineering is getting engineers
to consistently use effective methods, writes Watts Humphries in "Why Don’t
They Practice What We Preach?". For smaller teams, Craftsmanship is a more
appropriate metaphor than Engineering for getting developers work more effectively.
Craftsmanship has been a model that has been used throughout history to effectively
develop and disseminate arts, crafts and technology. By taking a sideways step
towards craftsmanship maybe we can eventually advance the state of the art so
that we can truly talk about Software Engineering.
- When you look at software, do you get the feeling that it has been developed
without adult supervision?
- Is software more critical to your business and yet becoming bloated and
- Are projects taking longer and delivering less than promised?
- Can you tell when a software project is going off track?
- Is licensing software professionals really going to make any difference?
- The "software crisis" has existed for years and there is still
a shortage of good software developers, because mechanical metaphors for software
development don’t work.
- Software engineering has fixed many of the technical problems, now we need
to focus on the social and cultural aspects of software development
- Extreme Programming works by paying attention to the craft of software development,
on what developers do on minute by minute basis
- Software Craftsmanship allows developers to creatively blend Art, Science
and Engineering to deliver great systems
This book is unique in that pays attention to the new reality of software
development - People are the most expensive resource. Unlike practically all
other industries, software is becoming more, not less labor intensive. As the
cost of computers has fallen, and computers have become pervasive, our model
for developing software has not adjusted to match these new realities.
Looking back into history, the problem of expensive labor and arcane skills
was handled by Craftsmanship, with beginners being apprenticed to the craft.
By prematurely adopting an engineering metaphor, the software industry has deskilled
developers before it has found a way to create an effective software factory.
This book is a call to arms to say that we must insist that developers really
know their craft before we trust them to create systems for us.
Some Interesting Ideas to play with before you read the book
- Software Craftsmen should sign their work. This will enable them to build
up a portfolio of applications that can be a basis for their reputation. This
will allow the software industry to move away from the various interview games
that are played and instead base hiring on an audition model (page 144).
- Once you have hired the lead Software Craftsman for you project, let that
person hire the rest of the team. Who they hire will let you know a whole
lot more about whether they are going to successfully deliver than any amount
of time spent in interview games.
- Software engineering was once characterized as being aimed at "managing
hordes of 'average' programmers working on large teams that continue for years".
Software Craftsmanship in contrast is about exploiting the productivity differences
between individuals and using really small teams of good developers. If companies
do this right they can afford to pay great developers what they are worth
because they will stop overpaying for average talent (page 61).
- Start exposing the fallacy of good enough software. Bugs do not infect
software and the cost of removing bugs does not increase as we eradicate the
bugs (page 56).
- Licensing of software developers is an illusion, it is an attempt to fix
the wrong problem. There was a very good reason why
the ACM withdrew from the attempt to define a Software Engineering Body of
- Software engineering is the wrong metaphor for the majority of software
development projects. By encouraging us to use a mechanical metaphor we end
up making mistakes because it tricks us about the true nature of software
development - that it is a social, intellectual activity, not a mechanical
one. Small wonder then that the Mythical Man Month problem still exists, the
way we talk about software development encourages us to think about "plug
replaceable programming units" and hiring a six pack of Java programmers.
For small projects we have to realize that the classical division of labor
approach just does not work (chapter 3).
- We must reverse the decline in the quality of developer training. Learning
software development is not the same as being taught how to program. Apprenticeship
is more effective than training to learn a craft, since it is more about learning
than it is about teaching. Apprenticeship deliberately avoids the "learned
helplessness" of the schooling model by making the apprentices an integral
part of the software development team (chapter 12).
Robert Martin of Object Mentor Inc.
posted the following on Usenet
McBreen hits the nail on the head! This book is a MUST READ for all CxOs,
VPs, Directors, Mangers, and Software Engineers. It will change the way you
think about the software development industry and profession.
In Software Craftsmanship, McBreen exposes the weaknesses of our current
system of software engineering, and proposes an alternative model based the
older apprentice/journeyman/master model. McBreen makes the point that building
a software project is not akin to product manufacturing. We don't have factories
that stamp out software. Rather we have groups of people trying to massage software
into place. McBreen likens successful software development to blacksmiths, or
silversmiths. To McBreen, software is a craft that takes years to learn, and
more years to master. The only way to properly learn the craft is to be taught
at the side of a master.
McBreen's thesis emphasises something that is missing from software development
today: attention to quality, and attention to expertise. The dotcom frenzy saw
thousands of startup firms throwing young untrained bodies at complex software
projects. The idea was that a programmer is a programmer is a programmer. The
more you have, the faster you get done. McBreen counters this concept by showing
that large software systems are better built by small teams comprised of masters,
journeymen, and apprentices, than by large teams of plug replaceable programming