Expectations of Oracle Technical Books – The Path to Positive Book Reviews

5072010

July 5, 2010

It might appear that my last two, three, four or maybe even five Oracle Database book reviews were a bit harsh. In some of the blog articles leading up to the last two book reviews I pulled out a sentence or two from the book and offered readers of this blog an opportunity to comment on the accuracy of the quote from the book. Was I just nit-picking the book’s contents, or is there a reason for the analysis?

It is probably best to start by defining some of what I believe to be the most critical key targets for a technical book:

A technical book must be non-fiction – a technical book should describe technically accurate details of an event, action, or object.

A technical book is a permanent record of an event, action, or object. With that in mind, the contents of a technical book should require a significant amount of research, testing, and retesting to verify the accuracy of the book’s contents not just in a Linux virtual machine, but also in physical hardware on Unix, Linux, and Windows. If the book’s technical content only applies to a Linux virtual machine environment, readers will likely experience trouble implementing the suggestions in a production environment.

A technical book that describes a feature should correctly identify with which Oracle release version the feature works.

A technical book that describes additional cost options such as partitioning, AWR, Database Replay, etc. should identicate that the feature must be purchased and/or is not available for the Standard Edition.

A technical book that describes Oracle initialization parameters must avoid mentioning the hidden initialization parameters unless a warning is provided that such parameters should not be modified without first consulting Oracle support. Mentioning that warning a hundred pages after the description of the first hidden parameter is of limited help.

A technical book that states feature X is 25% (or any percent) more efficient than feature Y should provide a reproducible test case so that the reader is able to test the efficiency improvement in their environment as well as adapt the test case to more accurately model a problem in the reader’s database configuration.

A technical book should provide forward and backward references to help readers locate detailed or advanced adaptations/implementations located elsewhere in the book. Also helpful are references to external resources found in other books, Metalink/MOS, or specific websites.

A technical book that contains “recipes” or “lab projects” should provide all of the critical configuration elements within a couple of pages of the “recipes” or “lab projects” – forcing the reader to page through hundreds of pages to piece together the “lab project” is unexceptable.

A technical book that advertises “undocumented secrets” or “definitive” or “complete” on the front cover had better contain actual undocumented (not in the Oracle documentation and not in Metalink/MOS and not found easily through an Internet web search) facts and/or contain the complete description of the topic.

A technical book should look like a technical book: 10 point or smaller font size, small margins, no cartoon drawings, well organized topics and sub-topics, few if any spelling or grammar errors, helpful table of contents and index, meaningful chapter names, few unnecessary distractions, etc.

A technical book should draw the reader in – trick the reader into reading the book cover to cover even when the weather is better suited to outdoor activities.

A technical book’s author(s) should have a reputation for producing accurate information about the subject – a Google search is helpful.

A technical book should cover the current release of the product (Oracle Database), as well as older but still supported releases.

And last, but not least, a technical book should convey useful content that helps people just starting to learn Oracle Database, as well as people who have used the product for years and are just looking for new ideas or a way to help maintain their knowledge. A technical book that introduces nothing new is of limited value.

I certainly do not know everything about Oracle Database – in actuality I probably know very little about everything that there is to know about Oracle Database. To say that it bothers me when I find errors in technical books, especially about Oracle Database, is an understatement – especially when it is something as commonly understood as the description of the db file scattered read wait event. Spelling errors, especially when an Oracle feature or initialization parameter are involved, simply should not be present – odd synonyms for well known Oracle keywords also should be avoided to limit confusion. A clear, professional writing style is appreciated.

If I buy a technical book and do not receive the above, I feel a bit cheated. The above will hopefully explain the seemingly harsh tone found in a couple of my book reviews.

What are your thoughts? What are your expectations when reading a technical book?

Related

Actions

Information

6 responses

5072010

Gary(06:00:14) :

“A technical book should cover the current release of the product”

I think that would give an unfairly short life to many books. In fact I’d be pretty sceptical of a book released within a couple of months of a new release coming out (except for a fairly dry ‘New Features’ volume from Oracle Press). As long as it clearly states what release was used during compilation, that should suffice.

I also feel there are is room for separate books for total beginners which wouldn’t be of any use to an experienced practitioner, and for books which assume a degree of prior experience. I offer up Jonathan Lewis’ CBO Fundamentals book as one which I would not recommend to someone with less than a couple of years of SQL experience.

You might have read a couple of sections of this blog article a bit different from what I intended – I finished the blog article at midnight, so that might explain why there is more than a single valid interpretation of the article. It is hard to disagree with your points (because I agree with the points that you made). Thank you for adding your comments – those comments help to counter-balance my points.

Books, because they are permanent records of an event, action, or object, should not have a short shelf life. Take, for instance, Jonathan Lewis’ other Oracle book “Book Review: Practical Oracle8i: Building Efficient Databases” (I added a link to the review for the book after seeing your comment). Jonathan’s book includes descriptions of a number of bugs found in Oracle Database 8.1.5 and 8.1.6 – while that fact could very well mean that the book is useless for those people using Oracle Database 11.2.0.1, the book includes information that bridges the gap between 8.1.6 and 11.2.0.1. In my experience it is rare to find timeless books that are written for the computer industry.

Solely covering the current release of the product is also a shelf-life limiting factor, as you pointed out. It probably would have been better to state “include coverage of” rather than just “cover”.

Perhaps some of your reviews are harsh. On the other hand, those harsh reviews give a lot of credibility to your reviews. When you say “This book is recommended” – I know that you were satisfied with both technical accuracy and the delivery of the content.

For example, I initially shunned “RMAN Recipes” book because the title indicated a lot of ready scripts with little explanation. As a result of your review I decided that the book is worth buying.

My reviews typically include those items I find in the book that I would want someone directly reporting to me (or someone working with me or someone seeking my advice) to know before reading the book – what to look for, and what (and why) to ignore an item in the book. The parts of the book that I do not mention would probably rate somewhere between OK and good. As I read the books I try to maintain detailed notes of the book contents. Unfortunately, I typically miss a couple of problems (and sometimes highlights) in books simply because I do not test/verify everything in the books. Unfortunately, the review I wrote for the “Troubleshooting Oracle Performance” book does not follow the same pattern – that was the first book I felt compelled to spend time reviewing due to the excellent quality of the book.

Your initial opinion of the “RMAN Recipes” book is largely the same as my initial opinion of the book before I had a chance to read the book’s contents. Needless to say, I was surprised to find the book’s format extremely helpful. Please feel free to share your opinion of the book.

Yes, I have disabled comments on all book review posts. There are a couple of reasons for doing that, but the primary reason is to make certain that the book author (and readers) does not mistake comments made by readers of this blog for my review of the books (example of such mistakes may be easily found on the various WordPress/Blogspot blogs).

If you have an account on Amazon you should be able to add a comment to one of my book reviews there (or rate the review if you decide that it is worth your time). Or, you can post your comment into this blog article.

Hints for Posting Code Sections in Comments

********************
When the spacing of text in a comment section is important for readability (execution plans, PL/SQL blocks, SQL, SQL*Plus output, etc.) please use a <pre> tag before the code section and a </pre> tag after the code section:

<pre>

SQL> SELECT
2 SYSDATE TODAY
3 FROM
4 DUAL;
TODAY
---------
01-MAR-12

</pre>
********************
When posting test case samples, it is much easier for people to reproduce the test case when the SQL*Plus line prefixes are not included - if possible, please remove those line prefixes. This:

SELECT
SYSDATE TODAY
FROM
DUAL;

Is easier to execute in a test case script than this:

SQL> SELECT
2 SYSDATE TODAY
3 FROM
4 DUAL;

********************
Greater than and Less than signs in code sections are often interpretted as HTML formatting commands. Please replace these characters in the code sections with the HTML equivalents for these characters: