Most fundamentally, I wrote my book because I wanted to make the world of software development accessible to many more people outside the software industry.
I had accumulated a lifetime of experience as a software developer. In that time, I had come in contact with many individuals who I would consider to be outstanding developers. I study these people to understand what they knew that made them so great.
What I learned is that everything that experts know, we can know. And when we do, we can get very similar results.
I’ve seen team after team reinvent the wheel, so to speak, until I tried to help them normalize around certain practices that would give them the most benefit. This is really what *Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software* is about. It discusses what I have learned about applying these practices correctly and some of the pitfalls that teams can fall into when they don’t understand the purpose behind practices.
I feel like there are a lot of how-to books on the market that cover most of the practices in Agile, but very few books really delve into *why* the practices are important. My book focuses on the motivation behind the practices so we can better understand and use them more effectively.
I knew these practices were effective because I helped some of the top teams in the world apply them. I saw developers struggling to make many of these practices work but only because they failed to see some key distinctions. When I showed developers these distinctions, they were typically able to overcome many of the challenges they were experiencing. Many continue to use these practices years later.
Since I was successful in coaching and teaching teams how to use these practices, they avoided many of the common pitfalls of adoption. I wanted to be able to find a way to write this down and share it with a larger audience through a book, but I found writing a very challenging process. I tried for nearly a decade to sit down and write out my ideas, but they always came out rather boring.I figured if my text bored me then it will surely bore a reader, so I threw it out and started over.
And over.
And over.
It was nearly a decade of trying and I had accumulated a lot of text but it wasn’t forming a coherent whole.
And then I came across a book with a strange title by Steven Manning called How to Write A Book on Anything in 14 Days or Less Guaranteed. I thought it was a joke but I picked it up and I started reading.
The first thing I noticed was how easy it was to read his text. The information just seem to flow. The author was very encouraging to the reader and this was something I wanted to do in my book as well. There are also several misspellings and punctuation errors leading me to believe he used the techniques he was suggesting to write his own book.
His ideas are sound: have something to say, write an outline and then expand that outline into what he calls a blueprint that includes keywords and phrases that you want to use as well as transitions from one topic to the next. I think of the blueprint as my script, living with my filmmaker wife, I get exposed to narrative storytelling and I try to incorporate that in my non-fiction writing as well.
I used beats to map out my blueprint. A beat in scriptwriting is the character’s next objective. Actors map these out on their scripts so that they know at any moment what their character is doing or thinking or feeling. I try to do the same thing with the material I bring to my dictation sessions so I have a good sense of not just what I want to say but how I want to say it. I also leave a lot of time for unscripted material though after I go over an idea, I’ll just keep talking about it, asking and answering myself questions about it to deepen my understanding.
Manning says the faster you write, the better your write and I think that’s true for me.
It always seemed that I had a bandwidth problem in the past. My mind would go faster than my hand could capture. I tried typing and writing out on hand but I still could write fast enough so I’d lose my place and get confused.
Previous Post: « A Billion Here, a Billion There
Next Post: Discussing Beyond Legacy Code on Agile for Humans »