Letters to ERCB

From: Suzanne Rotondo
Sent: Friday, January 16, 1998 4:44 PM
To: editors@ercb.com
Subject: fairness and accuracy in reporting?

Dear Editor,

I've written to ERCB before because I'm a Developmental Editor for Sybex Computer Books. The reason I wrote last time was to point out the complete absence of any of our technical books from your review section. While I can accept that there is some stiff competition in many areas of programming books, I find it hard to believe that none of our books have warranted a review from your staff.

Several of our books, including Mastering Java 1.1 2nd Edition, Java 1.1 Developers Handbook, and Visual Basic 5 Developers Handbook, have received many glowing reviews and excellent sales.

While you're certainly under no obligation to include our books, it's struck me as particularly odd that you have such a positive review of Barry Boone's Java Certification Exam book -- particularly since the book has been heavily criticized for countless inaccuracies and being rushed to market.

On the other hand, we have released a new (published in Sept.) book on the exam called Java 1.1 Certification Study Guide, authored by the Sun employee who wrote to the exam for Sun. It has received stellar reviews for both content and accuracy.

I would be more than happy to send a review copy your way so that you can offer some balanced, perhaps even more useful, information to your readers.

Please let me know that you received this message, and whether you'd be interested in checking out a copy of our Java 1.1 Certification Study Guide book.

Thanks a lot,

Suzanne Rotondo

Our reviewers pick out books based on their own interests and our Reviewer's Guidelines. We do not, and can not, commit to any attempt to give "balanced coverage" in the sense of reviewing an equivalent number of books from each publisher. Some publishers release an astonishingly high percentage of useful and unique books (O'Reilly is the prime example), while other publishers have a rather more dismal track record based on "Kick-Ass" books, "Dummies" books, "Idiots" books, etc.

All that having been said, we do encourage all publishers, including Sybex, to send us copies of books that fall within our review domain. We can't review books that we have never seen!

-- RD

From: Lucy Garnett
Sent: Tuesday, February 3, 1998 5:20 PM
To: editors@ercb.com
Cc: lgarnett@newton.baruch.cuny.edu
Subject: Review rebuttal

Rick Miller, in his review of my book Building Business Applications Using C++, is justified in saying that the book is "Marred by Sloppy Editing".

I did not exercise a sufficiently obsessive level of control over the production phase of the book. I relied upon the editing and production staff of the publisher to format the text, source code, page headings, and table of contents, to catch typographical and grammatical errors, and to turn my rough drawings into the final diagrams. Although some of the diagram errors were my fault, others were introduced between the time when I last looked at the galley proofs and the final book. The stylistic conventions of source code were correct in the manuscript which I submitted to the publisher, and when I saw the scrunched-up code in the galley proofs it was very difficult to return the code to its previous state --- moreover, some obvious compiler errors were introduced between the galley proofs and the final book.

I will address these issues in the next printing.

The twelve reviewers who provided suggestions, corrections, and comments about the content of the book while it was under development were not responsible for sloppy editing which took place during the final phases of the book's production.

In response to the Miller's criticism that "The Scope is Too Broad", it was never my intention to write a book which teaches how to produce commercial ready, "industrial strength" business applications. My book is written to provide an industrial strength programming methodology, at the level of a one-year introductory programming course, for students in information systems. The book is aimed at novice programmers.

The reason I wrote this book is because there was no other book on the market that had this approach. There was no other book which implemented classes and methods from the beginning---other C++ books were either aimed at those experienced in procedural programming, or were simply procedural programming books with objects and classes tacked on at the end. There was no other book which, at an early stage, showed how to organize and develop multi-filed source code necessary to manage large projects.

I have written a book which achieves all these goals. My book is successfully used by instructors in my department and other departments, in various first year programming courses. Whatever it is that makes this book work is not addressed in Miller's review.

To my deep regret, Miller was distracted by the errors. Once he perceived the errors, he was not as interested in reviewing the book on the merits of its accomplishments: "The more errors I found in the text, the more I wanted to read. It was like playing a game and to keep score I created an error matrix..."

I appreciate his error matrix, and I wish that my copy editor had produced a similarly comprehensive matrix.

But---Miller's game reveals that having judged the intrinsic worth of the book based on production level errors, now he was out to validate that judgement.

Let's look at the heart of Miller's review, which quotes from my book and then attacks the book based on that quotation:

Perhaps the numerous errors in the text can best be explained by this passage from Chapter 11, page 486:

"Bugs almost inevitably creep into complicated algorithms. One of the attractive features of object-oriented programming is that code is written in the expectation of being used over and over in solving many different problems. Reuse helps reveal bugs in the code. Upon detection of an error, a class method can be rewritten without necessitating changes to existing consumer code that already uses objects from that class, as long as the public interface stays the same. The longer a class has been around, the more confidence we, as consumers, have in it."

I see what she's trying to say, and perhaps it's unfair to twist the preceding paragraph into the author's editing cycle manifesto, but too much bad software has been written, and is still being written, with this attitude. It appears as though the author released this book to the public with the same philosophy at heart.

In today's world of black-box programming, the objective should be to make your classes bulletproof. The software engineering profession is already under close scrutiny because of slipshod design and poor programming practices. The author's philosophy of develop while you design and let the bugs work themselves out is amateurish at best and flies in the face of professional programming ethics.

Now, how is the software engineering profession going to achieve this objective? By using a programming methodology that maximizes the ability to detect and correct errors. That is the whole point of the above quotation from my book, and that is a message which I convey over and over throughout the book.

The object methodology is particularly well suited for finding and removing bugs, because of:

• Reusability of classes.
• Abstraction of what an object does from how it does it.
• Encapsulation of methods and attributes.

During program development, the problem solving cycle is iterative. The cycle should be repeated as often as needed, during development, until there are no detectable bugs. Only then should the programmer consider releasing the software. And even then, despite the heaviest commercial and ethical pressure to produce "bulletproof" software, despite the most modern programming methodology, there may still be bugs. One advantage of software written using the oop methodology is that bugs in the source code can be corrected more accurately and with fewer side effects.

Any computer programmer who advocates a slipshod philosophy of "develop while you design and let the bugs work themselves out" is deserving of any criticism that can be dished out. But who holds to this philosophy? Not the author of the book under review.

The reviewer's misinterpretation of the passage quoted from the book has the same effect as a common rhetorical technique: if you print a big enough lie, a casual reader will be bullied into believing you. More careful readers of the review, and of the book, can judge for themselves.

For instance, the passage quoted above follows a long discussion on the importance of testing the boundary conditions of a method for removing items from a linked list. In the paragraph immediately preceding the above quotation, I encourage the reader to consider further the question of whether the method is provably correct, even after there are no detectable bugs: "How do you know whether or not a method is correct? How confident can you be that this algorithm is correct and has taken into account all of the boundary conditions? It is hard to prove, with mathematical certainty, that a method will work all the time. Experience helps avoid common pitfalls. Once you have coded a program, test it extensively to make sure it works under lots of test conditions."

Why didn't the question ever enter the reviewer's head: "I'm making such an outrageous charge, could I be interpreting the author incorrectly?" I can only conclude that the reviewer, thinking he had found a smoking gun, decided to play it up for all it was worth.

Sincerely yours,
Lucy Garnett