One of my primary reasons for starting this blog is to try to share the experiences I’ve had while working with many different dedicated professionals in the software business over many years. I think there’s a lot to be learned from them, and from observing what has worked and what hasn’t.
In my observations, I’ve noticed two different kinds of professional developers: Those for whom software is a job, a thing they do between nine and five, a skill they know how to perform, and that they perform in order to get paid.
The other group doesn’t seem to think of software development as a job at all, more of a calling, an obsession, a passion, a drive. Most of the time they’re doing software development all the time – when they’re not actually programming they’re reading about it, thinking about it, learning about it.
A number of individuals in this second group not only have a passion, but a drive to excellence, and a high level of dedication and professionalism. I believe these individuals are software craftsmen (and craftswomen, as quite a few of them were not men at all, but I’ll stick with the one term to include both).
Software craftsmanship is a term that has been used more recently to describe a distinct approach to building software. Instead of a constant compromise between time (money), functionality and quality, craftsmanship proposes a model that enables developers to take responsibility for what they produce, eliminating this concept of compromise, where we have to pick any two to maximize at the expense of the third. A no-compromise model, where you get all three maximized.
It does this by focussing on improvement in the individuals, and therefore the team (if there is a team), instead of trying to manage external factors such as tools and processes. It rejects the notion that a larger number of mediocre developers is in any way comparable to a few dedicated professionals.
One of the foundational books about software craftsmanship can be found here: Software Craftsmanship: The New Imperative.
The craftsman takes responsibility for the entire process of software creation, and does not defer that responsibility to others – he (or she) does not complain about the specification, the timeframe, or any other external constraint. At the same time, the craftsman doesn’t shy away from the unpleasant truths. He will not commit to deliver something in a timeframe that cannot be done, or with features that cannot be achieved in that time. Far too many software projects are complete or partial failures – the craftsman knows that it is not acceptable to contribute to the chance of failure by making promises that cannot be kept, and does not participate in a death-march project.
On the other hand, the craftsman can make promises that are beyond other developers, as he makes it a point to know his capabilities, and at the same time to be continually and intentionally extending those capabilities.
Software craftsmanship at it’s core involves the purposeful practice of pushing one’s own abilities further and further all the time. As one of the best ways to learn something is to teach it, it is enlightened self-interest to share that knowledge and experience with others who wish to learn. This is the apprentice pattern that is often associated with craftsmanship.
As the craftsman takes full responsibility for his own production, the only way he can gain confidence in sustained success is to build tests, so test-driven development and extensive automated verification seems to be a natural outgrowth of taking on this responsibility.
The craftsman is almost always also a good businessman, as it’s not possible to know what the right thing to build is without an understanding of the business need you’re trying to fill.
In terms of actual development, the craftsman is always striving for code quality, not only because he takes pride in his work (which he does), but because it’s the most economical and effective way to build software in a sustainable way. Low quality software is like buying something on a high-interest credit card – you might seem to get what you want sooner, but in the medium to long term you’ll pay through the nose.
One of the masterworks on software quality was authored by the same man who used the term software craftsmanship much more widely than before: Clean Code: A Handbook of Agile Software Craftsmanship
He has written extensively about the craftsmanship concept, and how it impacts modern software development.
The final aspect of craftsmanship is that the craftsman is not only always trying to improve himself, but also puts significant effort into helping other developers reach higher levels of effectiveness as well.