What factor(s) influenced your decision to write a book on this particular topic? Was it, for instance, that you saw patterns in the development world around quality of code that caused you concern? Thank you to you and the JavaRanch folks for bringing this to my attention! All the best!
There were quite a few reasons to why I decided to write this book.
The main one was that Software Craftsmanship is a subject that is very close to my heart. I've started coding when I was 11 years old and since then I fell in love with software development. In 1999, more than a decade after I wrote my first line of code, I came across this crazy thing called XP. At first, that made no sense to me. A few years later, already living in London, I heard about Agile, where they were also talking about XP. That caught my attention and I decided to read more about XP and Agile. Around the same time, I also came across the Software Craftsmanship book by Pete McBreen and The Pragmatic Programmer by David Thomas and Andrew Hunt. These two books changed the way I saw the world.
As the Agile summit happened in 2001, the same year that Pete McBreen released his book, Software Craftsmanship didn't really become a thing. Agile overshadowed almost everything in that period. It was not only until 2008 that Uncle Bob and a few others in Chicago created the Software Craftsmanship movement, almost as fix to the bad turn that Agile had taken (too much focus on process and not much on technical practices).
In 2010 I started the London Software Craftsmanship Community (currently the largest and most active SC community in the world with 2500 developers) and helped many other Software Craftsmanship communities to be created in Europe. And since 2010, I've been heavily involved with the international Software Craftsmanship community.
Many things happened since Pete McBreen wrote his book, Agile being the biggest. The motivations for the Software Craftsmanship summit in 2008 were different from the ones that made Pete McBreen write his book. And after more than a decade of Agile, Software Craftsmanship needed a modern take—a book that could reflect what Software Craftsmanship means today, 14 years after the original book was written.
I also felt that I had acquired enough experience as a developer (almost 2 decades writing code professionally) and enough knowledge about Software Craftsmanship to share my ideas and hopefully write a book that could represent what Software Craftsmanship means today. My aspiration is that this book will help many developers to look at their careers in a different way and hopefully help us to move our industry forward.
It seems like we have journeyed on very similar paths. I read Kent Beck's XP Embrace Change book in 1999 as I was about to bail on a $56M failure of a project. I read Martin Fowler's Refactoring book at about the same time. Both these books immediately resonated with me and I can say it was almost an epiphany. I was determined to learn all I could about XP and refactoring. I even wrote on the inside cover of my Beck book, "In five years, this how all successful software projects will be done!" and I dated it circa Dec 1999. It didn't quite play out as I expected and it took me 6 more years of slogging it out on dysfunctional waterfall projects and honing my TDD and coding skills on the side before I got my current job and stepped into the role of Agile evangelist and agent of change for technical excellence.
As I said in the other thread, I have had Pete McBreen's book for a long time too. I don't think I got it as early as when XP burst onto the scene and gained many followers but I'm sure it was soon after that, probably around the time that the Pragmatic Programmer book came out.
I want to thank you again for writing this book and bringing a focus on technical excellence in engineering practices. I feel that there are too many developers out there who are just chasing one new technology after another without really understanding the underlying principles that help form the foundation for good quality software. It's just so easy to get mesmerized by these new shiny things and the promise of big bucks if we learn how to use them. Without a good understanding of basic software development principles, however, these developers are the ones who make life difficult for the rest of us. This needs to change. I'm all for Uncle Bob and company's push for more professionalism in our field and I wish you the best in your efforts to push this agenda. Good luck with the book. We need more developers to read it.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
I very much appreciate you taking time to respond to my question. I wholeheartedly echo your's and Junilu's accolades about XP. I was indirectly involved in a project awhile back at the company I work for where they introduced the XP concept and I was very intrigued with it. It seemed, at least to me, a complete paradigm shift from what I had in my mind of what developing was all about.
It seems to me that, given the importance of technical excellence in this day and age of "Get it coded and out to market as quickly as possible", the timing of your book, in my opinion, couldn't have been better planned. Cheers.
Yes, of course, and I accept that blame. In fact, i covet that blame. As does this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop