What is Software Craftsmanship?

I first started hearing about software craftsmanship when I started working at LinkedIn. It wasn’t a familiar term to me, but intuitively it felt like it was an apt metaphor. It invokes the sense of pride in workmanship, quality, elegance, and attention to detail that software engineers aspire to.

I thought it would be interesting to explore what “software craftsmanship” is, and where the term came from. I was surprised to find more controversy than I expected.

Our view at LinkedIn — and I’m saying this not because somebody designated me to define company policy, but rather because this is just how we talk about craftsmanship here (it’s even on our internal Wiki page) —?is that craftsmanship is one piece of what we call engineering excellence.

We call it engineering because engineering is all about recognizing constraints and negotiating the right tradeoffs between them.

This deliberate pairing of engineering and craftsmanship seems to fly in the face of where the craftsmanship movement started, which criticized the emphasis on programming as a form of engineering.

Pete McBreen wrote the book Software Craftsmanship in 2002. Although he says that craftsmanship and engineering are not opposed to each other and can happily coexist as two different traditions, he sharply criticizes the engineering approach for treating the building of software as if it were a kind of predictable deterministic process like manufacturing a car.

Except there are no software engineers who believe that. When a software engineer says that she is “building ” her code, she most likely referring to the automated process where the computer converts the code into some kind of runnable form, not the process of writing the code.

For the parts of the software creation process that are predictable and deterministic, we create tools to do those things for us. If the process of building and deploying code is like manufacturing a car, then the process of writing the code is much more like creating the design for the car.

One big difference between designing a car and developing software is the pace of development. There’s the old joke that if automotive technology had kept pace with computer technology, then today you could buy a car that goes 10,000 miles per hour, weighs 30 pounds, gets 1,000 miles to the gallon, and costs $50.

Mary Shaw gave a SATURN 2015 keynote address, Progress Towards an Engineering Discipline of Software , that explores the relationship between software engineering and other kinds of engineering.

What she explains is that every form of engineering goes through a maturation process where what starts off as a craft gradually evolves into a more systematic and codified form. Software engineering has not yet fulfilled all of the characteristics of engineering, but progress continues to be made.

Margaret Hamilton , Director of the Software Engineering Division of the MIT Instrumentation Laboratory and lead software engineer of the Apollo Project, shown here standing next to the code that was used to take humanity to the moon (1969), defended her use of the term “engineering”:

Software during the early days of this project was treated like a stepchild and not taken as seriously as other engineering disciplines, such as hardware engineering; and it was regarded as an art and as magic, not a science. I had always believed that both art and science were involved in its creation, but at that time most thought otherwise. Knowing this, I fought to bring the software legitimacy so that it (and those building it) would be given its due respect and thus I began to use the term “software engineering” to distinguish it from hardware and other kinds of engineering; yet, treat each type of engineering as part of the overall systems engineering process. When I first started using this phrase, it was considered to be quite amusing. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. Software eventually and necessarily gained the same respect as any other discipline.

So, if software development is a kind of engineering, what aspect are we emphasizing when we refer to craftsmanship?

There was a talk at SATURN 2016 about software engineering in the U.S. Air Force . They were having problems with software project schedules not matching their original estimates. The presenter, Paul Braden , conducted an efficiency study where he constructed a model for project workflow and then applied his model to actual projects.

For the study, he broke down projects into four categories based on project complexity, ranging from “simple” to “very complex”. His model estimated that a very complex project would take more than twice as long as a simple project (443 vs 211?days).

When he compared his model to actual projects, he found that simple projects actually took longer than very complex projects.

What explains this unexpected result? The crucial difference was that the center always assigned its best developers to the most complex projects. Braden’s conclusion: productivity depends more on the quality of the programmer than on the complexity of the project.

This is another real-world confirmation of what Fred Brooks published in The Mythical Man Month (1975).?

Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude.

— Fred Brooks , No Silver Bullet ?(1986)

This is the central theme of software craftsmanship, that better developers produce better software. Teams of great developers map their deep application knowledge into a computational architecture and apply best practices for developing clean code.

The use of the term craftsmanship is deliberately borrowed from guilds (organizations of artisans that control the practice of their craft).

Like an apprentice learning from a master craftsman , a software developer often learns a lot on the job. New developers learn what they need to know through the guidance of mentor figures without having to rely upon trial and error.

Surgeons have a maxim for teaching their craft that embodies this same philosophy, SODOTO: See one, do one, teach one.

Frank Shamrock , the MMA fighter, hit upon a similar formula that he calls plus, minus, and equal:

I also developed a system for teaching and learning that seems to work in every part of my life… In order to be successful in any part of my life, I need a plus, a minus, and an equal. I need someone who is my plus, who can teach me. I need someone who is my minus, who I can teach. I need someone who is my equal, so I can test myself.

This isn’t to say that one only learns from master to apprentice. As any engineering practice matures, what was once learned through trial and error or through oral tradition eventually becomes systematized and codified.

Science often arises from progressive codification of practice.

— Mary Shaw

Robert C. Martin (aka “Uncle Bob”), author of Clean Code , is a passionate advocate for software craftsmanship and a codifier of best practices. He talks about the idea of learning from a mentor, but also how one can value workmanship for its own sake.

One of the things about being a craftsman is that you learn how to work, and you develop a certain amount of pride, in fact a good deal of pride, in the way you work.

— Robert C. Martin

What Martin is saying is that one can derive satisfaction from the actual process of doing the work and learning, not just from the final product. It means that there is an opportunity to feel accomplished and productive every day.

Craftsmanship evokes several aspects. Not just a devotion to producing a fine product, but also a mindfulness and appreciation for the process. But we see also why craftsmanship is still just one piece of engineering excellence because one can learn from mentors and from teaching others, but also from the growing body of reference materials that contain knowledge and experience in codified form.

****

Please join the conversation...

What do you think? Comment below.

Thanks for reading. Please like and share. You can find my previous LinkedIn articles here (https://www.dhirubhai.net/today/author/davidpmax ).

Cover art: April 1, 2015: Motorola would like you to know that craftsmanship applies to selfie sticks too .

Other articles about craftsmanship at Linkedin :

• Leadership, Craftsmanship, and Execution by Kevin Scott
• What is Craftsmanship and Why is it Important? by Sanjay Dubey
• From Good to World-Class: What Makes Software Engineers Excel at their Craft by Alex Vauthey
• Software Artisans: Craftsmanship as a Competitive Advantage by Donnie Flood
• Measuring Craftsmanship by Joshua Hartman
• Notes on “Clean Code” by Mohamed El-Geish