Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
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.
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
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
Excellent message in this post.
A lot of this carries over to class design and coming up with intuitive names for types and operations.
Unleashing Office 07 with Visual Studio 05
A Microsoft guide to POWER!
Much better title.
If the upcoming naming post could address any of the situations I described in http://msmvps.com/blogs/jon_skeet/archive/2009/02/27/what-s-in-a-name.aspx that would be lovely :) (In particular the difference in naming for immutable types vs mutable types will hopefully become more and more relevant over time.)
@Brad: There's another way Eric gets tech reviewing gigs, but he may be too modest to mention it: when authors do everything in their power to get him. If you were writing a C# book, can you think of anyone you'd rather have? :)
The blogosphere is a small world: when I read this I immediately thought of Jon Skeet's recent post, and by the time I get to the comments there is already a link to it :)
This is the best example of the power and importance of naming that I have ever come across, and I appreciate your analysis. Krzysztof often makes similar points in his talks about the Framework Design Guidelines. I think the most important point, and at the same time the point that is most often overlooked, is that the name should reflect the goal that is being accomplished, not the method by which it is being accomplished. Users may sometimes care about the how, but they ALWAYS care about the what.
'Managing Enterprise Systems With The Windows Script Host' vs 'Automating Windows Administration?'
Let me offer a more extreme example: 'Complete Chronicles of War Between Mycene Forces and City-State of Troy' vs 'Iliad'. How's that?! :-)
My point is, a title should be, above all things, straight to the point. And if it takes more than three words to get there, well, that begs a question of how clear the point is to the author (or the editor) him/herself, in the first place (no offense to anyone!)
The obvious exception would be the marketing requirement to mention a product described (i.e. Visual Studio 2010 - three words already, if you count the year as one word).
Maybe it's just me who's linguistically challenged, but l-o-n-g titles, especially with a lot of fancy terms in them, tend to make my mind bluescreen and go into an emergency shutdown. Then I become a bit like a corporate executive: 'give me the bottom line, please!' :-)
While I'm at it, how about something like 'C#-iad' instead of 'Fabulous Adventures in Coding?' :-)
Just kidding, sorry. I've been reading too much heroic fantasy...
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: 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?
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.