Writing a Book About Oracle: Art or Science?

by Chris Lawson

INTRODUCTION: THE BOOK EXPLOSION

A casual scan of the bookshelves at any large bookstore reveals an interesting trend: There are more and more Oracle books available today, from an increasing number of publishers. The number of new titles has exploded just in the last few years -- almost as fast as Oracle releases new database versions!

New Oracle books are printed almost as fast as Oracle releases new database versions!

This huge expansion of new titles also means that there are lots of opportunities for new writers. Presumably, these books are all being published because there really is a big demand for good database books. To exploit these opportunities, however, some preparation is required. The question is, how should the aspiring writer get started? What is involved?

In this article we explore one author's experience in writing a technical book about Oracle. We will answer questions such as:

How much time is required?
How difficult is it really?
How do I gain credibility?
Where do I start?
How does the edit process work?
Is it worth the effort?

For Oracle DBAs, designers or developers interested in writing a book on Oracle (or any other technical subject), I hope you find my experience useful. Perhaps this information will save you some time, or alleviate some concerns. I do not claim to be an expert on publishing books, but I think my experience could be useful to you if you are considering writing a technical book.

HOW MUCH TIME IS REQUIRED?

As the dot-com bubble was starting to burst a few years ago, it became likely that in the (near) future I would have some spare time on my hands. It dawned on my one afternoon that I could use this extra time to do something that I had considered for some time-write a book on Oracle performance tuning. I wanted to write a book more for the beginner, as opposed to the very sophisticated books really intended just for the "guru."

I have always enjoyed performance tuning and other database "mysteries," and I wanted to show the novice performance tuner how to get started. I wondered, however, how much time would be required. Could I keep up with tough editing deadlines?

I was fortunate enough to have someone who could help me get started. Don Burleson, editor of Oracle Internals and author of numerous Oracle books, was kind enough to offer some suggestions. He estimated that a first book would require an investment of 360 hours.

Don was very accurate. Here is the breakdown of my actual time spent writing and editing the book:

240 hours for the first draft
130 hours for the first set of edits
15 hours for answering questions during the second edits.

You can see that my total time investment was 385 hours. This time was spread-out over 6 months or so. This means that I spent about 15 hours each week just working on the book.

HOW DIFFICULT IS IT, REALLY?

If you were to just look at the number of hours required, you might get the impression that the whole job is really pretty simple. Just 15 hours a week-how tough can that be?

A few hours focused exclusively on writing can be a very draining activity.

Nevertheless, if you were to begin a book-writing project with the idea that it is going to be easy, you would be sadly mistaken. That 15 hours per week is a very tough 15 hours. To my surprise, I discovered that writing a book is far more difficult than writing technical papers.

Why is it so difficult? For one thing, the scope of the job is much broader than a single technical article. For a single article, you can become the subject matter expert without spending an enormous amount of effort. Now, compare that to writing about 20 technical papers! That roughly gives you an idea of the work involved.

Another big hurdle is the need for technical accuracy and timeliness. The book I wrote was about 400 pages, which is not really very large for a technical book. Nevertheless, for each of the 14 chapters, I needed to be technically accurate, clear, and up to date.

In the Oracle world of fast database releases, techniques and ideas that are technically accurate in one database release may be outdated in the next. I discovered that some processes and techniques that I used had become obsolete with Oracle 9i. For instance, my method of gathering statistics using the Analyze command is really on the way out. Thus, I found it necessary to research and document the newer method suggested by Oracle. There were other techniques that I had to research as well.

HOW CAN I GAIN CREDIBILITY?

Publishers are interested in selling lots of copies of the books they publish. They can more easily do this if they sign-up an author who is already well known, or at least has some impressive credentials. These well-known authors are oftentimes the speakers you see at the large national Oracle conferences; they draw a huge crowd every time they speak.

Remember the saying, "Nobody except a blockhead ever wrote, except for money."¹ This is true for publishers as well as writers. Publishing houses are not in the business of printing books for charity; they want to maximize the chances of success. That means either using an established name (e.g., Kevin Loney, Rich Niemiec, Thomas Kyte), or using an author who has otherwise proven his or her writing ability. In other words, the publisher wants someone with credibility.

"Nobody except a blockhead ever wrote, except for money"

Probably the easiest way to enhance your credibility is to write articles for technical journals. Besides the local user groups, they are numerous technical journals that are happy to review submissions-even from unknown writers.

Many popular Oracle authors have used this strategy. For instance, Don Burleson advertises that he has penned over 100 articles! In contrast, why would a publisher listen seriously to someone who has not bothered to publish even a single technical article?

WHERE DO I START?

Before your book project can start, the publisher will want to see a detailed proposal for your book idea. This proposal should include an analysis of the market for your book, the anticipated competition, plus detailed chapter outlines.

I wrote the original proposal for The Art and Science of Oracle Performance Tuning in December of 2001. Although very supportive, the first publisher I contacted already had contracted for a book on a similar topic. Naturally, they did not want to compete with their own book.

The second publisher I contacted, Curlingstone (a subsidiary of WROX), was interested in reviewing the proposal. I emailed the book proposal to Curlingstone, and they hired a small group of highly respected DBAs² to review my proposal. (At the time, I didn't know that Curlingstone had signed-up such a renowned team.)

THE CONTRACT

If your proposal fits the needs of the publisher, they will offer you a contract. They will possibly want you to consider certain changes, based on the comments from the reviewers. In my case, the senior editor wanted me to consider including material on ways to prevent performance problems. I agreed to include this whenever possible.

If you think that you will get rich from your book royalties, think again. As a first-time author, you will be given a small advance (typically a few thousand dollars), and a minor percentage of the net sales. Your advance will probably be spread-out over several months, and paid upon completing certain chapters. As part of your compensation, you will also given a handful of free copies.

In return for your advance, you will be obligated to deliver chapters according to an agreed-upon schedule. You can simply email the chapters to the editor.

HOW DOES THE EDITING PROCESS WORK?

Once you have completed your draft of the entire book, you will enter the editing phase, in which you work with one or more editors assigned by the publisher. I found the editors a very reasonable and professional group of people. They did not claim to be super DBAs, but they were certainly very competent writers.

The publisher will hire a review team who are experts in the field. They will review each chapter, and make suggestions on where the manuscript could be improved. You will then have to review their comments and make appropriate changes.

I found this stage to be very trying, and much harder than I thought. Consider this: Every paragraph of every page in your book is subjected to intense scrutiny by a group of people you probably don't even know. Although my reviewers were well qualified, I found it to be no fun to have my writing subjected to such a rigorous critique.

Of course, the final product was undoubtedly much better because of this review, but that doesn't make it any more fun! (A football player may become a better athlete by "running the gauntlet," but he probably doesn't look forward to it.)

The reviewers will be of varying skill levels and backgrounds. At times, they may become confused, or you may believe that their comments are completely wrong. For instance, the main technical editor suggested that 50% of the OS-specific material should be Windows. He wanted to substantially trim down the Unix section and add much new material on Windows. My experience has been that Unix is a much more important platform, so I argued against his suggestion. (I ended up adding several pages on Windows, but not removing any of the Unix material.)

At other times, the reviewers may contradict each other, and you will have to use your own judgment. I remember one section toward the end of a chapter. Here is what two reviewers said about the same section:

Reviewer 1: "Eek!" [I think she didn't like this section.]
Reviewer 2: "This is great. I will make my entire staff read this."

Since I was aiming for controversy in the book, I left this section unchanged. If nothing else, I felt it would get a good discussion going.

In another chapter, where I talked about indexing, here is what two other reviewers said:

Reviewer 1: "Be sure to remind the readers to rebuild indexes regularly."
Reviewer 2: "There is no basis whatsoever for rebuilding indexes."

Once again, my theory was confirmed: If you get 10 DBAs in a room together, you will get 10 different "right" ways to do something.

I found the most helpful suggestions to be comments such as "I don't understand what you're saying." This type of comment told me that I had not really communicated well. I almost always took action to modify a section whenever a reviewer made a comment like this.

Keep in mind that the reviewers' comments are mostly suggestions and observations based on their personal experience. Rarely are technical issues so black and white that there is really only one correct answer. Of course, you would be wise to seriously consider most remarks; by doing so, I learned quite a bit from the reviewers. Naturally, errors in syntax or usage should always be corrected.

After the first stage of edits, things move rapidly. I was surprised at how quickly the editors incorporated and reviewed all the changes. There were actually only a few remaining technical questions, plus some formatting difficulties. (Did you ever notice, for example, exactly how the output is formatted in Sql*Plus for numbers versus text?)

OFF TO THE PRINTERS!

Once all the edits and reviewer questions have been addressed, there are just a few more minor issues to handle. You will have the opportunity to write/review a few preliminary sections, such as the Introduction, Acknowledgements, and Dedication sections. I found these to be very simple.

Finally, when you have answered all the editors' questions, and the proofreaders have blessed the work, it will be sent to the printers. There's really little for you to do at this point, except relax!

At this point, you will probably also receive another portion of your advance.

AFTERWORD: WAS IT WORTH THE EFFORT?

Writing a technical book about Oracle databases is a formidable challenge. I found it to be one of the most difficult things I have ever done. Ironically, I could not have done it without the big "dot-com meltdown." I simply would not have had the time.

For me, the toughest part in writing The Art and Science of Oracle Performance Tuning was wading through the myriads of comments from the technical reviewers. Facing a huge amount of critical comments can really test your patience.

There really isn't any other way, however. No one has all the answers; everyone makes lots of mistakes. This means that an extensive review process is necessary in order to build a good product.

Now that it's all over, I can look back and smile. I have learned a lot more about Oracle, and some of my faulty ideas have been corrected. (Not all, though, I still have a few more.)

Now, getting back to those reviewer comments . . .

¹ Dr. Johnson
² Steve Adams, Thomas Kyte, and Jonathan Lewis

**Chris Lawson is a DBA consultant and author of The Art and Science of Oracle Performance Tuning (Curlingstone). He specializes in performance tuning of data warehousing and financial applications. Chris is also the editor of the online magazine, The Oracle Magician, available at www.OracleMagician.com.

Return to the March 2003 issue of The IWJ.