When was the last time you wrote a code that was not protected with unit test/refactoring? When was the last time you fixed a bug reported in a legacy code base that was full of bad code? When was the last time you saw a class with more than 100 lines of code? How many times have you allowed code to be shipped to production with bugs (that is, with a known bugs list)?
Maybe this sounds familiar. If so, you're probably asking: What can we do about this? Why is this bad code there in the first place? How can an ethical professional allow this to happen?
I wonder where the craftsmanship in software has gone. I wonder why we acknowledge buggy products as part of life and work. It's time to raise the bar.
According to some, "Software craftsmanship is an approach to software development that emphasizes the coding skills of the software developers themselves. It is a response by software developers to the perceived ills of the mainstream software industry, including the prioritization of financial concerns over developer accountability."
Software craftsmanship is all about putting responsibility and pride back into the software development process. As Andrew Hunt and David Thomas state in The Pragmatic Programmer (1999), and Pete McBreen points out in Software Craftsmanship: The New Imperative, we need to act like other craftsmen and start "signing our work."
The idea of software craftsmanship is not new. It started way back in 1992 and gained momentum when McBreen's book was published. The idea was that software developers need not see themselves as part of the engineering tradition, and that a different metaphor might work better.
In August 2008, Bob Martin proposed a fifth value for the Agile Manifesto: "Craftsmanship over crap" (which he later changed to "Craftsmanship over execution"). After that, a variety of conferences keep the ball rolling. Today, multiple software craftsmanship conferences take place worldwide, organized by different communities.
In December 2008, a group of software craftsmen met in Libertyville, Illinois, and crafted the Software Craftsmanship Manifesto, stating:
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 partnerships.
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
Characterization of a software craftsman
The software craftsman will "do it right" even under pressure. He takes responsibility for what he committed to. He takes pride not only in his end product but also on the process toward it. He is proud to sign his work.
The software craftsman is a continuous learner. When she doesn't work, she spends her time studying, finding new methods and tools to improve her work. She writes code. She practices deliberately and understands the difference between practice and work. She practices in order to be prepared for work. She also contributes to the community.
"Baby steps" — remember this principle. Start with following software engineering best practices, including test-driven development (TDD), continuous integration, refactoring, pairing, and a feeling of pride and an attitude that QA should find nothing. These practices help us start the journey to become a software craftsman.
To iterate with ever-shorter timeboxing, to get multiple feedback for the work implemented, to automate as much as possible, to take responsibility for one's individual professional career and apply what you've learned, and — most important — to slow down in order to go fast are some of the other behaviors that help us become software craftsmen.
How Agile software development can help achieve software craftsmanship
Agile software development relies on a fundamental fact: that teams are self-managing and self-organizing. Self-managing and self-organizing will happen only if the teams are empowered. When teams are empowered, they have more ownership and pride in the work they do. This results in better-quality output.
Most of the recommended disciplines mentioned above are activities practiced by many Agile teams (especially Scrum teams). Ken Schwaber says those practices go hand-in-hand with Scrum teams; certainly I have seen them followed by Scrum teams across many organizations.
Agile software development gives a lot of opportunity for the software engineer to walk the path toward becoming a software craftsman.
Finally, I would like to conclude by saying that software craftsmanship is not a destination or a goal. It is a journey that every software professional should try to be part of, one that will add value to the profession.
My thanks to Kati Vilkki, manager and Agile coach, for helping me connect the dots to get the bigger picture of software craftsmanship with empowerment. This article also contains references to points taken from speeches given by "Uncle Bob" (Robert Martin) and Corey Haines (Coderetreat.org).