A Book By Any Other Name Would Smell As Sweet

As you might have gathered from my previous posts on the subject, I occasionally edit technical books as a hobby. It’s nice having a hobby that pays money instead of costing money. And I always learn something from every book.

Many years ago, on one of my first editing gigs, the editor asked me my opinion on what the book’s title should be. At the time I had no particularly coherent thoughts about how to title a book, but I’m almost always willing to offer an opinion on things I know little about. So I thought about it for a few minutes and responded that since the book was about how to manage enterprise IT systems by writing scripts that use the Windows Script Host, that the title should be “Managing Enterprise Systems With The Windows Script Host”. After some back-and-forth discussion between me, the editor and the author, we actually settled on that title, amazingly enough.

This is not a very good title for what is really a quite good book. I realize this now, with the hindsight of a lot more experience in thinking about how to name things.

Were I asked to criticize this title now, with that hindsight, I’d ask myself some pointed questions:

Q: Is “managing” what the target customer of the book describes themselves as doing?

A: Maybe sometimes, but we can do better. The target audience typically describes themselves as “systems administrators”, not “managers”. Cut “managing” and replace it with “Administering”.

Q: What function does the word “Enterprise” serve?

A: It discourages home-computer users from buying the book. Which is good, because they are not our target audience. But “Managing” or “Administering” already does that. It also discourages small- or medium-business sys admins from buying the book and they are in the target audience. Cut “Enterprise”.

Q: Do we really need to call out that the things being administered/managed are “Systems”?

A: No, obviously that goes without saying. Cut “Systems”.

Q: Then what noun is the object of the verb “Administering”?

A: We need to tell the potential reader that this is a book about administering Windows. The noun “Windows” must be in the title somewhere. Admins of other operating systems are explicitly not in our target audience and we must discourage them from buying this book. We look disingenuous if we don’t do that.

Q: What does “With Windows Script Host” communicate to the potential buyer?

A: It logically ties the book to a particular tool used to solve the customer’s problems. It puts the emphasis on the solution mechanism rather than on the customer’s problem.

Q: If the customer needs a circular hole in a wall, do they care much about who manufactured the drill and the drill bit?

A: No. Though there are better and worse drills, good enough is good enough. As long as the drill works reasonably well, they mostly care about the result.

The implementation details of the solution are not particularly important to the customer, even if they’re the person doing the implementation. What’s important to the customer is the benefit obtained by taking the advice in the book.

Q: What is the compelling overall benefit to the customer of using the advice in the book?

A: They can write scripts to automate tasks, putting in some up-front time to write the script and accruing the benefit of having a previously time-consuming and irksome administration task performed quickly and automatically by the script host.

Whew. That was a lot of pointed questions.

I wasn’t there for this conversation, but I imagine that the editors and author went through a similar mental process when they prepared the second edition for publication. The second edition has a far better name: Automating Windows Administration. It contains keywords “Windows” and “Administration” which attract the target audience – professional administrators of Windows-based systems – and repels people not in the target audience. And it leads with the compelling benefit to the customer: automation. “Automation” makes work easier. Leading with “Managing” puts the emphasis on the hard part of the job, not on making it easier. And the new name doesn’t tie the book or the reader to committing to a particular toolset.

Good naming is a hugely important aspect of design; the name of a thing is almost always how the thing first enters the consciousness of a potential consumer. Next time, we’ll explore some more aspects of what makes a name “good” or “bad” for a particular purpose.

Comments

• Anonymous
  April 02, 2009
  Heh - how about emailing a copy of this blog post to the guys that named "Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System"? Oh, believe me, they got my opinion loud and clear when that decision was announced internally. (And thus my long-running joke about how long the name of the book about it should be.) -- Eric

• Anonymous
  April 02, 2009
  How do you get a job editing technical books anyway? That might be a lot of fun and save me some cash too (although the MSFT company library has already saved me from buying a lot of technical books). Well, I can tell you how I get gigs. When an editor needs a technical reviewer for a book about a Microsoft product, they look at who blogs about the product and they watch who goes to conferences to talk about that product. Then they email those people them asking for help finding editors. So they find me in pretty short order. My first gig came about when someone from Wrox Press attended a talk I gave on scripting in 1997 and asked me afterwards if I'd be interested in reviewing their forthcoming books about the stuff I'd just been speaking about. Easy as that. I'm sure there are other ways as well, but I wouldn't know what they are. -- Eric

• Anonymous
  April 02, 2009
  Excellent message in this post. A lot of this carries over to class design and coming up with intuitive names for types and operations.

• Anonymous
  April 02, 2009
  Unleashing Office 07 with Visual Studio 05 A Microsoft guide to POWER! Much better title.

• Anonymous
  April 02, 2009
  The comment has been removed

• Anonymous
  April 02, 2009
  The comment has been removed

• Anonymous
  April 02, 2009
  The comment has been removed

• Anonymous
  April 03, 2009
  There is one benefit in the original title: it's more obvious what it's actually about - what the reader should expect to learn. Suppose I wanted a book on WSH. The company I work for (hypothetically, don't forget!) has a vast amount of WSH code, and I've been asked to maintain and extend it. I need to know more about WSH. I'm not interested in the general task of automating Windows administration - half of a book with the new title might be about PowerShell rather than WSH, for example, which wouldn't help me at all in this hypothetical situation. All I'm saying is that sometimes the particular tool is prescribed (either from above or after analysing the alternatives) and that a title which makes it clear which tool it will solve the problem with is a good thing. Jon

• Anonymous
  April 03, 2009
  Jon: In that situation, I'd consider any book that appears to involve WSH, which would include one on automation.  But then I've have done a small amount of research.  Perhaps a tagline or quote on the cover beginning "Practical WSH..." would fill the gap. Denis: what are you implying is fantasy?

• Anonymous
  April 03, 2009
  Mark: It's just my references to Iliad and that sort of things; I'm not imlying anything by this. Also, I have known a few authors of that particular genre, one of whom also started up as an editor, and they have given me a lot of interesting information as regards to the author-editor-reader relationship. Also, I should probably say that, unlike most technical people, I would take an easy-to-remember catchphrase over a logically correct, but sometimes hard-to-digest precise description any day. I believe they call it 'demagogic technique' in politics: appealing to the mass beliefs, prejudices, fears, suprestitions, or what have you, as opposed to strictly logical arguments. And boy, have I seen it work! :-) More to the topic, both the best title and the best book I have ever read on programming (it was C++ programming back then) was 'Enough Rope to Shoot Yourself in the Foot', by Allen Holub.