For a long while now I’ve been musing on this blog about some of the ideas surrounding what we call “software craftsmanship”. After all this musing, I’ve realized that the topic is large enough and important enough to explore more deeply.
As many in the industry have observed, software is getting (arguably, already is) incredibly important to the normal functioning of our daily lives, and it appears this trend is likely to continue for some time. This alone, even if not for the many other reasons, is sufficient to take software craftsmanship seriously, and to explore it’s meaning and it’s disciplines.
I’ve had the good fortune to make my living in the software development industry for almost three decades (it’ll be 30 years this June, if I remember correctly), and in that time I’ve seen what I would call good craftsmanship, and I’ve seen what I will charitably refer to as – well – “not” good craftsmanship, and I’ve tried to pay attention to the differences between them. I’ve seen some technologies and techniques come, then go, then in some cases come again, a couple even for the third time. As has been many times observed, if we do not study history, however brief, we are doomed to repeat it – for better or worse.
I’ve seen what works, and what doesn’t, and I’ve thought and talked about why, and I’ve decided to try to summarize those experiences into an exploration of the subject, concentrating on the underlying principles or beliefs of good software craftsmen and the practices that usually derive from those principles.
I’m going to summarize my musings here in the blog, but I’m also planning on writing a full-length book on the subject. Tentative title “Software Craftsmanship: Principles and Practices”. I’m not sure yet if it’ll be only an eBook or if dead trees will be involved, but that’s just the details of delivery.
Any work of this nature is going to be far more valuable to other developers if it includes as many perspectives as practical, so I welcome input, comments, collaboration, discussion, dissent, digression, debate, disbelief and all that other stuff as well.
My audience for this book will be the aspiring software craftsman. Software is in the unfortunate position of being such a new discipline that there’s not a large body of knowledge easily grasped by the apprentice that’s not specific to an area of technology. To use a medical analogy, we’ve got books on treating broken fingers aplenty, but not that many on the general experience of being a doctor. Of course, if we imagine a world where the idea of doctors has only been around for fifty years or so, this lack is more understandable. Still, how can we develop more good software craftsmen (and craftswomen, of course), if those of us that have been kicking around for a while don’t record and share our experiences?
In any event, please expect a torrent of thinking on this topic to be poured out here starting soon, and please drop me a line if you’d like to get involved in the process. You’ve been warned!