7 of 8 people found the following review helpful:
5.0 out of 5 stars
Still useful but contains certain aporias, December 9, 2001
This review is from: Developing Windows Error Messages: Error Messages that Communicate (Paperback)
Ben's book is well-written and well-edited and provides a number of useful ideas on how to write effective error handlers and error messages in the Windows environment. It's focus may seem strange to nonprogrammers, but programmers appreciate this sort of guidance on details.
However, Ben does repeat some saws or maxims which need to be deconstructed.
One is that at one time, error messages were overly terse because "there was not enough storage" to make them useful.
I find this disingenuous, because the dreamtime to which Ben is referring to is probably the early 1980s. In the early 1980s, I was as a former IBM 1401 programmer (whose first machine ten years prior had 8000 characters of storage) in awe of the possibilities of the primitive disk and tape systems then available.
On the 1401 I had developed a system which used an "overlay" and a supplemental manual procedure to provide a user with fully expounded error messages in English, and by the early 1980s, providing my users with English error messages was not a problem.
The idea that at any time "we are limited by the gear available" is to me a confession that a certain need is not important enough to warrant our time. Basically, the need of users for error messages has always been triaged and continues to be triaged in an unconscious binary opposition between the "serious" and MALE tasks of programming, and the "not serious" FEMALE task of communication. To me the first mistake was to divide these tasks.
Another old saw Ben repeats is that "programmers", in inverse proportion to their skill level or interest in being "programmers" do not like to write, or cannot write.
This saw exists in a logical dependence on an idea from outside programming which is that there is such a thing as a content-free "skill in communication". Although a convenient corporate reification, useful for example in getting rid of racial minorities, women, and older employees on the basis that they are mistreated because of a generalized lack of "communications skills", the very idea that we can speak of communication without discussing content, or for that matter simple morality, is nonsense.
"Poor communicator" may be a true generalization as applied to the actual population of programmers in the United States. However, it is belied by a maxim of hero computer scientist Edsger Dijsktra, which is that programming ability is indicated by command of the language.
To the extent that programmers write overly terse error messages they may actually be, while statistically representative of American programmers considered highly qualified, less well-qualified than they could be.
This is because the only evidence we have that the programmer understands his system is something outside code.
Ben Ezzell himself shows he's qualified by not only writing good examples of error messages but also by being aware of what the user probably needs. He does so as a programmer who can code, and it is a false humility of his to say that programming skill has nothing to do with communications skill.
Managers love to give programmers books such as Who Moved my Cheese? and The Elements of Style, probably because these books rigorously exclude the content of the programmer's work from consideration. This may be useful in some cases but basically it is an attempt to deprofessionalize, for it denies that the programmer has learned anything worthwhile.
The managerial saw is that by definition "mere programmers" do not know enough to communicate with users and require by definition an interface consisting of people who do things like review, or actually compose, error messages. But inside the corporation, resources are allocated by non-market means despite the commitment to the free market, and the practical result is that most corporate employees seek first to avoid blame and are therefore not likely to compose forceful and hard-hitting error messages because in the corporation, the messenger is killed for bad news.
I am not dismissing the need for people to perhaps specialise in technical writing or even the composition of error messages...especially for international systems. It would almost be too much to expect programmers to know multiple human languages. What I don't like is the ideology implicit in saying that we must cultivate a content free communications style. I like Ben's book because it is ABOUT both programming and communicating.
The genuine quality of this book, together with its genuine aporias, indicates a need for a definition, outside corporate hegemony, of programming. This definition is needed because if programming is implicitly defined ONLY as MIS programming, it becomes impossible to develop effective systems for the public good...as evidenced by the real problems government and not for profits have in implementing systems; because of omnipresent cost considerations, many such organizations are forced to use off-the-shelf packages which encapsulate (at a deep level) assumptions valid only for private, for profit businesses in what are called "business rules."
A critical theory would define programming, not just writing error messages or documentation, as writing and not mathematical, while at the same time realizing that many practitioners seriously underestimate the applied mathematics of programming. In the present arrangements in the US, programming is considered mathematical and numerical in some sense, thereby excluding many people who could make a contribution, while in another sense, any form of real mathematics and real logic is excluded at the critical point in the development of many systems, usually when cost constraints can be used to justify hand-waving.
If I understood what Claude Levi-Strauss was talking about in expounding a way to read a myth against its own grain rather than literally, I would be able to conclude that American programming praxis is a form of systematically misreading an Enlightenment myth. This would help me to understand why such genuine talent and ability such as Ben's is on display in books from publishers like O'Reilly whereas in practice error messages STILL confuse genuine end users.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
2 of 3 people found the following review helpful:
3.0 out of 5 stars
Good for the novice progammer, June 23, 1998
By A Customer
This review is from: Developing Windows Error Messages: Error Messages that Communicate (Paperback)
I have finished reading all the sections of this book that I will read, and am preparing to find a new home for it. Overall, I am disappointed with this book, considering the publisher and price paid for it. Most likely, this expensive book is getting returned.
If you have no experience with creating suitable user interfaces for error messages and/or error handling, this book is a good place to start. It provides solid information on when and how to interrupt the user for various error types, and describes the various error types extensively. However, as an experienced programmer, I was looking for specific and new information about generating error messages. I really didn't find anything that was of any use to me that was related solely to error messages. Don't get me wrong - there is good information in this book, but most of it is based upon general, common sense ideas about user interfaces and error handling.
The thing that annoyed me the most was that the writing was too verbose and the book too long for the limited content found in it. I frequently found myself skipping over the personal vignettes looking for nuggets of useful information, and the "humor" was artificial and contrived - isn't this supposed to be a professional volume? The content in this book would be more useful and accessible if it were distilled and placed as a couple of chapters in a more general introduction to user interfaces book.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
