Writing and Publishing a Book

March 12, 2008 — Posted by Scott Bain

I recently completed the process of getting a book published ("Emergent Design"). It was my first time doing this, and I thought it might be valuable to some of you if I shared some of the things I learned about writing a book, and about the publishing world.

First, the reason I wrote the book dictated some of this. Al Shalloway and I have been teaching patterns, TDD, and so forth for a number of years now (adding all the other good folks at Net Objectives along the way), and we've always given a lot of attention to student feedback, to improve the course materials and to tweak our delivery style. Not surprising; Agile course creation.

Anyway, over the most recent few years, I would get the following comment on a very regular basis:

"Great class, man. Really useful. Unfortunately, I don't work by myself, and my colleague Fred does not go to classes. But if you wrote a book with the same great stuff in it, he'd read that. Could you write a book, please?"

Well, not exactly like that. J But there is always the notion that classes have inherent limitations: not everyone gets to/can afford to come, some people are elsewhere in the world, our instructors don't speak Chinese, etc... Books don't have the same limitations. They can travel, can be translated, and are relatively inexpensive. They provide a much greater reach.

Books have different limitations of course. They are static, they don't allow for interaction, and so on. I've created some online material that my book links to, in an effort to overcome some of this (www.netobjectives.com/PatternRepository for example).

Still, I'd never written a book before. So, in starting to write, I asked other people who'd already written good books how they did it. I asked Al and Jim Trott (authors of "Design Patterns Explained"), Gerry Weinberg, Jim Shore, Bruce Eckel, and basically anyone I came across who'd written a book.

Some said "Write a book you'd like to read." I'd heard that in other venues too; make the movie you'd like to see, write the tune you'd like to hear. I guess, sometimes, that's right.

But Al, Jim and Gerry all said "imagine a reader, the reader you have in mind for this book. Put the image of that person in your mind, and constantly ask... what would they want to know next? What question would they have here?" This works, of course, only if you feel confident that you know this representative person well enough to be able to answer these questions.

For me, this was the way, because I had been teaching for a number of years. As a result I had met literally thousands of developers, and knew the kinds of questions they asked, when they asked them, and what answers tended to satisfy them. So, that's what I did; I created a representative student to talk to. His name, by the way, was Vince. J

Now, it turns out that I made a bit of a mistake, but got lucky.

The mistake? I wrote the book, then went to the publisher. This can lead to a real disaster. You may have written a beautiful, smart, compelling book for which there is no market whatsoever. Even a great book that nobody wants to read is worthless.

In my case, I knew there was a market because the market had asked me to write the book. Still, if I'd gotten involved with the publisher earlier, several things would have happened:

  1. They would have kept me on a writing schedule. From time to time I got lackadaisical about getting the book done, and the publisher would have held my feet to the fire a little. That would have been healthy for me.
  2. They would have reviewed chapters as I wrote them, which would give me early and frequent feedback. In other words, I would have gained all the benefits of using a Lean/Agile approach.
  3. They would have helped me write. I didn't realize that publishers have extensive support mechanisms to help their authors; access to peer-review, copy editors, technical editors, and so on.

In other words, they would have really smoothed the process. As it was, after I thought I was "done" with the book, and I handed it to the publisher, we had to go through peer-review, technical editing, copy-editing, production formatting, and on and on, all of which we could have done as I wrote. It took 15 months after I thought I was done to get the book out.

So, don't do that. The next book I write I will come up with a general proposal, write a sample chapter or two, and probably outline the general shape of the book, and then contact my publisher and make sure there is a market, and then let them help me to write it efficiently.

As a last point, I cannot say enough about Chris Guzikowski and his editorial team at Addison-Wesley. I had some trepidations about getting involved with publishing people (which is probably why I put it off), but they were super to work with, really encouraging and supportive, and extremely easy on my ego. I don't know how that compares to publishers in general, but I really loved the process with them.

-S-

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Scott Bain

Scott Bain is an consultant, trainer, and author who specializes in Test-Driven Development, Design Patterns, and Emergent Design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban