As an industry we obsess about technology competence among individual programmers. This is important, but not nearly as important as we believe. Much more important is a programmer's pure expertise as a software craftsperson. This has several aspects.

Broadly, software craftsmanship concerns how teams of programmers view their relationships with their work, with their customers, and with each other. It is closely related to Agile Methods.

But more narrowly, what is well-crafted code? One key characteristic is extensibility. Good design is optimized to accommodate exactly the kind of maintenance and extension that customers have already demanded. Another chacteristic is simplicity -- omitting needless code (including anything that anticipates extension that has not already been demanded). Note that in an Agile context, good code is robust, as demonstrated by exhaustive, automated unit tests. In fact, the practice of Test-Driven Development naturally drives design toward extensibility and simplicity.

Most systems are not extensible or simple. They suffer from at least one of the Seven Deadly Design Smells listed in Bob Martin's excellent Agile Software Development: Principles, Patterns, and Practices (ASD:PPP):

• Rigidity (Changing one part of the system forces changes in other parts.)
• Fragility(Changes in one part cause bugs in unlrelated parts.)
• Immobility (System components cannot easily be isolated for reuse.)
• Viscosity ("Doing things right is harder than doing things wrong.")
• Needless Complexity (Infrastructure or abstraction without immediate, direct benefit.)
• Needless Repetition (Repeating code that could be unified under a single abstraction.)
• Opacity (The code is hard to read or understand.)

It takes tremendous skill and experience to prevent these smells from arising in high-traffic production code, in order to keep it soft and extensible. It also takes good judgement and restraint to resist adding infrastructure that anticipates too much change too soon, thereby creating Needless Complexity. Balancing simplicity and extensibility is the heart and soul of software craftsmanship.

Well-crafted code optimizes stakeholder return on investment. Another value of emerging Agile methods like XP is the way they require programmers to focus their efforts continually on delivering measurable business value.

Without continual, deep, broad communication, high software craft cannot happen. A true software craftsperson has the ability to write well, and to converse effectively and continually with project stakeholders. Agile Methods typically demand continual person-to-person conversation. I've written an article elsewhere on one aspect of these conversations: Empathetic Listening.

Another interesting development in the area of software communication is Eric Evans' notions of Domain-Driven Design. Eric makes a powerful case that business analysts and developers must together devise collective models and languages of the problem domain at hand, and that artifacts that convey them clearly (like UML diagrams and glossaries) must persist and be revised throughout the development lifecycle.

Technologies don't solve software problems; only skilled programmers can do that. Software craftsmanship is therefore far more valuable to your development operation than facility in any specific technologies.

The craftsmanship movement requires that companies value programmers more than the technologies those programmers use. The craftsmanship movement is also critically concerned with the systematic conveyance of knowledge from master programmer to apprentice.

For an excellent summation of principles, patterns, and practices of Agile software craftsmanship, be sure to read ASD:PPP. A lot of people waited a long time for "Uncle Bob" to finish this book.

For a well-reasoned and well-articulated argument for considering software development as craft, rather than as a branch of engineering, see Software Craftsmanship by Pete McBreen, as well as Pete's website.

For information on Eric Evans' provocative book on a new way for software project stakeholders to communicate about problem domains, check out his site at Domain-Driven Design.

For a thoughtful and far-seeing collection of articles on software high craft, check out Martin Fowler's website, and read all of his books.

For a brief and powerful compendium of programming techniques essential to accomplishing high software craft, see The Pragmatic Programmer by Hunt and Thomas, as well as their website.

For thought-provoking and illuminating discussion of issues related to high software craft, see Bill Venners' excellent artima website, which is full of articles and blogs by and about the masters themselves.

-- Patrick Wilson-Welsh, Adaption Software     revised 8/8/06

[More of Adaption's Articles.]