The term Software Craftsmanship seems to be rather divisive in its support, with, as mentioned in the book numerous times (along with retorts) the fact that the movement can come across as elitist. At it’s core it’s another manifesto, a fairly open-ended one at that, but having read the book it extends far beyond this.
In much the same way as Agile, in the pure sense, is more of a mindset than a prescriptive set of rules, the ideas behind Software Craftsmanship conveyed in the book really lean towards achieving excellence, building on and complementing a lot of the practices outlined under XP and Agile.
The book covers a range of topics, for me personally the areas I found to be of the most value covered Technical Debt, Saying No, Interviewing Practices (been doing a lot of these recently, and according to this book fairly badly!), Improving yourself, Pragmatism, and Leadership in the “getting people to follow your practices sense”.
There is a really interesting take on Legacy Code, one that I feel aligns quite closely with my approach. To paraphrase, it’s a challenge, not a chore. Refactoring is really rewarding once you become comfortable with the practice. I deal with a lot of Legacy Code in my day job, and this view point really resonated with me.
There are obvious parallels to The Clean Coder by Uncle Bob (my favourite software developer book) to be drawn. It’s in the same Robert C. Martin series so it’s not altogether surprising. There’s some overlap, notably the section on “How to Say No”, which I’ve referenced previously, is pretty similar, not that that’s a bad thing, it’s probably the piece I found most helpful starting out as a developer.
While not really mentioned directly, on reflection, my biggest take away from the book is not to make excuses. Any capable developer given unlimited time and resources can make applications with high test coverage and all the features under the sun. Unfortunately we live in the real world, and there’s nearly always something that comes up to prevent us from delivering what would be deemed to be the optimal solution. The book offers ways to combat this and get closer to the ideal, and at minimum to understand what and where the technical debt lies and make sure the relevant people are aware of the situation, i.e. product owners etc. The book also goes some way to dispel common myths and misconceptions around test driven development and clean code, e.g. it takes longer to deliver a project delivered using TDD, accompanied with ways to sell the benefits back to management.
In summary, it won’t be everyone’s cup of tea, the subject matter can come across as a little preachy, but it’s hard to disagree with the sentiments. I really enjoyed the read, with a lot of it being really relevant to where I am in my career at this moment in time, I’d happily recommend.
If you like this:
Have you read this book, or have any recommendations? Let me know in the comments section.