A Review of ``Softword: Provenance for the Word 'Software''' and Other Work by Paul Niquette

The book being reviewed here may be read from the following location, freely provided by its author:
http://niquette.com/books/softword/tocsoft.html

This book is very easy to read, and can be enjoyed over but a few hours.  It has a tone that reminds
me of ``Alan Turing's Electronic Brain'', albeit with far less in the way of technical details.  The
book concerns the coining of the word ``software'', which the author claims to have done in 1953; by
reading the book, I believe him.  It's amusing to have never given this topic thought before, though
I've enjoyed the humorous comparison of ``software'' to ``hardware'', with that ``firmware'' similar
to the pair; the author took it much more seriously, despite also using the word for a silly effect.

I see myself, in the author's fixation on proper use of language; in his insistence on keeping daily
records, which I do mechanically; in his opinions on correct software; and perhaps most in his notes
``101 Words I Don't Use'' which starts with the following: ``You can tell quite a lot about a person
from the words he or she uses.  You might tell even more from the words he or she does not use.''  I
was pleased to see I'd already been following his advice in some ways, not for the same reasons, but
by an insistence on using different words merely to do so, by calling ``bugs'' in software ``flaws''
or a ``debugger'' a ``revealer'', or through other language pedantry in which I merrily participate.

I find it curious how the author is careful in his usage of language, yet continues to refer to that
typical machine architecture as ``von Neumann''; I also do so, but I bemoan this for every instance.

The most valuable part of the book, which I read first, is in Appendix E: ``Software Does Not Fail''
http://niquette.com/paul/issue/softwr02.htm

Before reading this, I wasn't so careful with my usage of ``fail'', but have been convinced to be so
forevermore by this article.  No reason comes to mind as to why anyone at all interested in software
shouldn't read this article; anyone who has enough knowledge to understand how software is typically
written, and enough sense to be swayed to think like the author, will leave this article, rightfully
horrified at the sorry state of modern software.  It nicely accompanies many of my similar writings.

I'd like to coin a good word, but I'm still so searching; follows are some particularly nice quotes:

 Testing is the best way to assure quality, some people say. They are not sophisticated.
 Whereas proving that software works in a given sequence of cases can indeed be accomplished by
 testing, testing one sequence may or may not prove that the software works in another sequence.

 One handy software engineering tool is the 'debugger,' which is a misnomer tantamount to calling a
 'magnifying glass' an 'insecticide.'
.