Tue

Aug 16
2005

Marc Hedlund

Marc Hedlund

Don't Buy Tech Books that Don't Have Betas

While I was reading the final version of Agile Web Development with Rails today, I noticed that one of the pages, page 53, looked completely different than it had when I'd read the first "Beta Book" version of it (back when it was page 51). Three footnotes had crept up onto the page, two of them after the line, "That wasn’t hard now, was it?" Apparently it was harder than the authors had originally thought. One of the footnotes has a special warning for people running Mac OS X 10.4; another addresses a MySQL compatibility issue; and a third warns about an error you might get if you were still running an example from earlier in the book. I went back and looked at the earlier versions of the book, and the first beta copy had no footnotes; the second (of the ones I have) had one footnote; and the final had three footnotes.

It made me think: why would I want to buy a technical book that hasn't gone through this sort of public review? For that matter, why would I want to buy a cookbook without the same system in place?

The Beta Book program apparently made a fair bit of money for the publishers: more than US$50,000 on PDF copies alone, if I read David's numbers correctly. But the program did more than that -- it made the final, printed copy of "Agile Web Development with Rails" better for everyone who buys it -- not just the Beta Book participants.

Most or all tech publishers, including O'Reilly, use tech reviewers to ensure that the book is accurate and clear. (That is, in fact, how I first came to know the people at O'Reilly -- by being a tech reviewer on a CGI book back in the day.) But no tech reviewer would have caught all three of the notes needed on page 53. That's why I'm glad to be reading a book so many other people tried before it went to press.

It's what I would want from all the tech books I read. That's not so hard now, is it?


tags:   | comments: 8   | Sphere It
submit:

 
Previous  |  Next

0 TrackBacks

TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/4248

Comments: 8

  Peter Semmelhack [08.16.05 02:45 PM]

Isn't this type of interaction exactly what Wikipedia is successfully achieving? Call it open source editing, talmudic discourse, beta, whatever. Involving the users in the creation of something that will benefit them all seems extraordinarily valuable.

  Marc Hedlund [08.16.05 02:55 PM]

Peter,

Maybe. But the difference with the Beta Book is that it actually went to press. That's both good and bad -- of course Wikipedia gets bugfixes for the life of the page, and it's accessible from anywhere. So maybe the question is, what, other than profits, do you get from making a Beta Book into a print book?

I still like having a print book to read, but there's good reason to think that's a declining need.

-Marc

  Anna Martelli Ravenscroft [08.16.05 03:41 PM]

I really like the concept of doing a book online before committing it to hardcopy. One of the nice things about working on the Python Cookbook was knowing that the recipes had had time for review by others and the good ones were better because of the process.

  Kathy Sierra [08.16.05 05:54 PM]

For the Head First books, we definitely wanted a "wisdom of crowds" approach to the review process, but without making public betas. I described the process in a comment on Jim Minatel's blog:
http://wroxblog.typepad.com/minatel/2005/08/kathy_sierra_in.html.

My co-authors and I could not be happier with it! We've thought about public betas, but we decided not to go that way for a variety of reasons. The process we use now gives us a lot of the benefits of public betas without some of the drawbacks.

  Marc Hedlund [08.16.05 06:30 PM]

Hi, Kathy,

Thanks for the link to the description of your review process. It sounds good to me, and I can't argue with the results.

Other authors have more or less similar programs. My friend Peter, who recently wrote Practical Common Lisp for Apress, posted the whole of the book online (see <http://www.gigamonkeys.com/book/>) as he was in the process of writing it, and the comp.lang.lisp community, and other online readers, sent in comments and corrections. Steve McConnell used a process more similar to Kathy's for his second edition of Code Complete, but anyone could send in an email to become a reviewer. He also posted PDF chapters as they were completed. The Good Home Cookbook from Collector's Press is soliciting recipe testers on the Internet as well -- see <http://www.collectorspress.com/index.html?recipetester.html&nav.html>.

The Rails book is interesting in part because they charged people to be reviewers, you could say. Since there are no other Rails books out yet, people such as myself were willing to pay for early access to the text. Yet others (I did not) clearly also sent in corrections or comments. I like this model in that it benefits both sides -- the people who want early access (me) and the author (them).

  Dave Thomas [08.16.05 07:00 PM]

Inerestingly, we also did a peer review just like Kathy's for the Rails book. I use Yahoo groups for this: it's convenient and free.

We set up a private group and invite folks to participate. With the Rails book I had some 30+ folks in there. It works the way Kathy described: I posted chapters, and people comment.

I then use a simple system of e-mail folders to do workflow so I can go through chapter by chapter and include review feedback. Works great, and no special software needed.

Dave

  Swaroop C H [08.16.05 10:12 PM]

This is what Bruce Eckel does with his books.

  Tim O'Brien [08.18.05 11:08 AM]

Vincent Massol and I had a great team of Reviewers for Maven: A Developer's Notebook, and I think we ended up with a 99.9% "bug-free" first edition, but there are a few silly omissions and typos I would do anything to get a chance to fix.

Sometimes, it isn't that you don't have an adequate number of reviewers. It is simply that your reviewers are not representative of the general reader audience. An expert in a subject may be able to help you avoid missing a critical part of a project, but they won't be able to get into the same mindset as someone just learning a product.

Public, electronic betas solve this problem by getting feedback from the real audience. If you are not going to have a public, electronic beta, you should (at the very least) identify some real world users.

In other words, having James Gosling review your Java book is good for content, but you also need to find someone just getting into Java to give you real-world feedback.

Post A Comment:

 (please be patient, comments may take awhile to post)






Type the characters you see in the picture above.

RECOMMENDED FOR YOU

RECENT COMMENTS