Takeaways from Software Craftsmanship by Pete McBreen
One of the things that I am enjoying most about my apprenticeship at 8th Light so far is having the opportunity to read a lot of books. Now that I’m taking public transit to/from work, I have a lot more “semi-idle” time that’s perfect for reading. I mean, what else am I going to do on the train?
Although the 8th Light LA undoubtedly has a smaller collection of resources than Chicago, there is a nice little library of books to peruse. I will crack open a technical book from time to time (especially Joshua Bloch’s Effective Java), but I’ve mostly been using my reading time on the train for books on Software Craftsmanship.
The most recent book I’ve been reading is Pete McBreen’s Software Craftsmanship: The New Imperative, and I wanted to take a moment to reflect on my thoughts after finishing it for the first time. These are a few of the points I found most interesting.
Software Engineering vs. Software Craftsmanship
I’ve never thought too deeply about the different words used to describe the practice of creating software. Software development…software engineering…I detect some subtle differences in semantics and connotation between the two but in my mind which term somebody uses is either a reflection of their job title or a desire to seem more or less “science-y” (like I mentioned this was just a half-formed thought that I never investigated further).
Pete McBreen contrasts software engineering and software craftsmanship in terms of the circumstances of the projects from which each approach was born. Software engineering principles came about because of massive systems projects involving the design and development of hardware and software which involved hundreds or thousands of individuals working for several years. The idea of “big up-front design” in software makes more sense in this context, where the hardware on which the software will run is not available because it hasn’t been built yet. What else are you going to do with your time if not create detailed specifications?
In order to come up with an efficient process for designing and writing the software for this new hardware, people looked to traditional engineering for inspiration. Detailed requirements, extensive documentation, planning meetings etc. begin to seem more reasonable when you understand where people got the idea and the constraints under which they were working.
Software engineering is an approach that still has its uses today, but for those types of projects that are similar to those that gave rise to the approach (like the space shuttle program). The book goes on to talk about trade-offs involving cost, time, work-hours, the probability and stakes of system-crashing bugs (it’s not necessarily a huge deal if your word processor crashes, but a space shuttle software failure endangers human lives), and comes to the conclusion that for most projects today, software engineering is not the best approach for delivering reliable, cost-effective software quickly.
Unfortunately a lot of the research into software-creation methodologies and papers/books that have been published (especially in the 1960s and 1970s) concentrate on software engineering, which encouraged people to use that approach even when it’s ill-suited to the project. Most of the rest of the book focuses on the craft model of software development, but I appreciated learning about the engineering approach (and when it makes sense) to have a point of comparison.
Craftsman Sign Their Work
This one is a really simple idea, but I think it’s a kind of foundational root from which many other tenets of Software Craftsmanship sprout.
While at times I find the metaphor of Software Craftsmanship to be a bit of a misrepresentation of the medieval apprenticeship model (kind of like the modern interpretation of chivalry, which is far off from its roots in medieval literature), I think the idea of software craftsman signing their work to be a useful parallel.
Signing your work means you want people to know you created it. Your name is literally (or digitally) attached. But isn’t that a bit egotistical, like Trump sticking his name on everything he can?
Well no (and not only because I’m pretty sure Trump doesn’t build his buildings himself) — it’s a sign of pride, yes, but also a claim of responsibility. If you know you are going to be responsible for maintaining an application beyond its release date, it forces you to pay closer attention to detail and to consider how choices you make today are going to impact your ability to maintain and grow the application in the future.
Signing your work is a declaration of your intent to continue supporting an application in the future, until such time as you find a successor to take over stewardship or the application is retired. Your professional reputation is built on many things, but one of the most important is your portfolio.
Although one could see signing your work and taking on the responsibility of maintenance as a burden (and to some extent it is), it affords you the right to include the application in your portfolio, with your name attached. A portfolio of successful projects is a sign of a professional, even with digital artifacts like software.
There’s a lot more to say about this book, which is full of both theory and practical advice about the practice of Software Craftsmanship. I’m certain I’ll read it again in the future, and I recommend it to anyone else who’s interested in how to build great software. Right now it’s only $11 on Amazon…