Fabulous Adventures In Coding : Books

A Book By Any Other Name Would Smell As Sweet

Eric Lippert — Thu, 02 Apr 2009 16:09:00 GMT

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.

VSTO Book News

Eric Lippert — Mon, 09 Mar 2009 18:10:42 GMT

I am pleased to announce that my co-author Eric Carter has made significant updates to our VSTO book. (Though I notice with chagrin that one of the changes is that the title is much shorter than it ought to be.) It is not yet available in bookstores but will be soon.

The new parts of the book (which I did no work on at all, this one is Carter's baby!) cover the 3.0 version of VSTO in great detail; if you're looking for the definitive work on the subject, this is it.

See Eric Carter's blog for more details to come.

References are not addresses

Eric Lippert — Tue, 17 Feb 2009 21:10:00 GMT

[NOTE: Based on some insightful comments I have updated this article to describe more clearly the relationships between references, pointers and addresses. Thanks to those who commented.]

I review a fair number of C# books; in all of them of course the author attempts to explain the difference between reference types and value types. Unfortunately, most of them do so by saying something like "a variable of reference type stores the address of the object". I always object to this. The last time this happened the author asked me for a more detailed explanation of why I always object, which I shall share with you now:

We have the abstract concept of "a reference". If I were to write about "Beethoven's Ninth Symphony", those two-dozen characters are not a 90-minute long symphonic masterwork with a large choral section. They're a reference to that thing, not the thing itself. And this reference itself contains references -- the word "Beethoven" is not a long-dead famously deaf Romantic Period composer, but it is a reference to one.

Similarly in programming languages we have the concept of "a reference" distinct from "the referent".

The inventor of the C programming language, oddly enough, chose to not have the concept of references at all. Rather, Ritchie chose to have "pointers" be first-class entities in the language. A pointer in C is like a reference in that it refers to some data by tracking its location, but there are more smarts in a pointer; you can perform arithmetic on a pointer as if it were a number, you can take the difference between two pointers that are both in the interior of the same array and get a sensible result, and so on.

Pointers are strictly "more powerful" than references; anything you can do with references you can do with pointers, but not vice versa. I imagine that's why there are no references in C -- it's a deliberately austere and powerful language.

The down side of pointers-instead-of-references is that pointers are hard for many novices to understand, and make it very very very easy to shoot yourself in the foot.

Pointers are typically implemented as addresses. An address is a number which is an offset into the "array of bytes" that is the entire virtual address space of the process (or, sometimes, an offset into some well-known portion of that address space -- I'm thinking of "near" vs. "far" pointers in win16 programming. But for the purposes of this article let's assume that an address is a byte offset into the whole address space.) Since addresses are just numbers you can easily perform pointer arithmetic with them.

Now consider C#, a language which has both references and pointers. There are some things you can only do with pointers, and we want to have a language that allows you to do those things (under carefully controlled conditions that call out that you are doing something that possibly breaks type safety, hence "unsafe".) But we also do not want to force anyone to have to understand pointers in order to do programming with references.

We also want to avoid some of the optimization nightmares that languages with pointers have. Languages with heavy use of pointers have a hard time doing garbage collection, optimizations, and so on, because it is infeasible to guarantee that no one has an interior pointer to an object, and therefore the object must remain alive and immobile.

For all these reasons we do not describe references as addresses in the specification. The spec just says that a variable of reference type "stores a reference" to an object, and leaves it completely vague as to how that might be implemented. Similarly, a pointer variable stores "the address" of an object, which again, is left pretty vague. Nowhere do we say that references are the same as addresses.

So, in C# a reference is some vague thing that lets you reference an object. You cannot do anything with a reference except dereference it, and compare it with another reference for equality. And in C# a pointer is identified as an address.

By contrast with a reference, you can do much more with a pointer that contains an address. Addresses can be manipulated mathematically; you can subtract one from another, you can add integers to them, and so on. Their legal operations indicate that they are "fancy numbers" that index into the "array" that is the virtual address space of the process.

Now, behind the scenes, the CLR actually does implement managed object references as addresses to objects owned by the garbage collector, but that is an implementation detail. There's no reason why it has to do that other than efficiency and flexibility. C# references could be implemented by opaque handles that are meaningful only to the garbage collector, which, frankly, is how I prefer to think of them. That the "handle" happens to actually be an address at runtime is an implementation detail which I should neither know about nor rely upon. (Which is the whole point of encapsulation; the client doesn't have to know.)

I therefore have three reasons why authors should not explain that "references are addresses".

1) It's close to a lie. References cannot be treated as addresses by the user, and in fact, they do not necessarily contain an address in the implementation. (Though our implementation happens to do so.)

2) It's an explanation that explains nothing to novice programmers. Novice programmers probably do not know that an "address" is an offset into the array of bytes that is all process memory. To understand what an "address" is with any kind of depth, the novice programmer already has to understand pointer types and addresses -- basically, they have to understand the memory model of many implementations of C. This is one of those "it's clear only if it's already known" situations that are so common in books for beginners.

3) If these novices eventually learn about pointer types in C#, their confused understanding of references will probably make it harder, not easier, to understand how pointers work in C#. The novice could sensibly reason "If a reference is an address and a pointer is an address, then I should be able to cast any reference to a pointer in unsafe code, right?" But you cannot.

If you think of a reference is actually being an opaque GC handle then it becomes clear that to find the address associated with the handle you have to somehow "fix" the object. You have to tell the GC "until further notice, the object with this handle must not be moved in memory, because someone might have an interior pointer to it". (There are various ways to do that which are beyond the scope of this screed.)

Basically what I'm getting at here is that an understanding of the meaning of "addresses" in any language requires a moderately deep understanding of the memory model of that language. If an author does not provide an explanation of the memory model of either C or C#, then explaining references in terms of addresses becomes an exercise in question begging. It raises more questions than it answers.

This is one of those situations where the author has the hard call of deciding whether an inaccurate oversimplification serves the larger pedagogic goal better than an accurate digression or a vague hand-wave.

In the counterfactual world where I am writing a beginner C# book, I would personally opt for the vague hand-wave. If I said anything at all I would say something like "a reference is actually implemented as a small chunk of data which contains information used by the CLR to determine precisely which object is being referred to by the reference". That's both vague and accurate without implying more than is wise.

Book News

Eric Lippert — Mon, 12 Jan 2009 19:37:00 GMT

Happy new year all -- I hope 2008 was a good year for you and that 2009 will be better. I myself was crazy busy at the end of 2008, working on a number of at-work projects and personal projects which I'm not going to blog about at this time. I hope to get more time in the schedule for blogging in the next couple of months.

I want to start off the year with the belated announcement that we have shipped a printed and bound version of the C# 3.0 specification. Why would you want the dead-trees version when you can just get the Word document off the web? Because the print edition is annotated.

Yes, we were fortunate enough to get Brad Abrams, Joseph Albahari, Krzysztof Cwalina, Jesse Liberty, Fritz Onion, Vladimir Reshetnikov, Chris Sells, Bill Wagner, plus me, to write annotations for those areas of the specification that we each found interesting.

There are lots of good comments that elucidate tricky bits, give historical context, provide advice and guidance, rail against restrictions, and so on. My only complaints are that the annotations are so brief and that I wish I had had the time to more fully annotate every bit of the spec. But then again, that's a big part of what this blog is for, so I shouldn't complain too much.

The Future of C#, Part Three: On video, plus the dead-trees edition

Eric Lippert — Wed, 29 Oct 2008 19:48:00 GMT

Amazingly enough, it has happened again. Why does this keep happening to me?

Anders, Mads and Eric on C# 4.0:

C# 4.0 with Anders Hejlsberg, Mads Torgersen, and Eric Lippert - Part 1 of 2

C# 4.0 with Anders Hejlsberg, Mads Torgersen, and Eric Lippert - Part 2 of 2

Anders, Mads and Scott on the new dead-trees edition of the C# 3.0 specification:

The C# Programming Language, 3rd Edition

Enjoy!

Yet More Book News

Eric Lippert — Mon, 28 Apr 2008 17:42:47 GMT

It's a bookish day apparently. I am pleased to pass on news of the availability of the book Eric Carter and I wrote about VSTO, now in Chinese. Here is Jie Wang holding a copy of the original C# book and the VSTO开发指南 Visual Basic book:

Many thanks to Jie Wang, Mei Liang, and everyone at Addison Wesley and 中国电子工业出版社 (China Publishing House of Electronics Industry) who helped make this possible.

C# In Depth

Eric Lippert — Mon, 28 Apr 2008 17:19:14 GMT

Good morning, we interrupt our irregular and unscheduled ramblings with this breaking news bulletin: I am pleased to pass on news of the availability of Jon Skeet's new book "C# in Depth".

I had the privilege of being the technical editor of this book. But I've gotta tell you, when I unzipped the files sent from the publisher, the flattery began immediately. The "front matter" placeholder page read:

FOREWORD: To be written by someone really prominent, hopefully – Eric Lippert, perhaps?

Hah! Don't think I went easy on the book because you buttered me up, Jon.

In all seriousness, I was very pleased and honoured to be asked to write the foreword to Jon's excellent book. This was by far the least work and most fun I've had doing technical editing, and the foreword practically wrote itself. Here's what I whipped up:

There are two kinds of pianists.

There are some pianists who play not because they enjoy it, but because their parents force them to take lessons. Then there are those who play the piano because it pleases them to create music. They don’t need to be forced; on the contrary, they sometimes don’t know when to stop.

Of the latter kind, there are some who play the piano as a hobby. Then there are those who play for a living. That requires a whole new level of dedication, skill and talent. They may have some degree of freedom about what genre of music they play and the stylistic choices they make in playing it, but fundamentally those choices are driven by the needs of the employer or the tastes of the audience.

Of the latter kind, there are some who do it primarily for the money. Then there are those professionals who would want to play the piano in public even if they weren’t being paid. They enjoy using their skills and talents to make music for others. That they can have fun and get paid for it is so much the better.

Of the latter kind, there are some who are self-taught, who “play by ear”, who might have great talent and ability but cannot really communicate that intuitive understanding to others except through the music itself. Then there are those who have formal training in both theory and practice. They can explain what techniques the composer used to achieve the intended emotional effect, and use that knowledge to shape their interpretation of the piece.

Of the latter kind, there are some who have never looked inside their pianos. Then there are those who are fascinated by the clever escapements that lift the damper felts a fraction of a second before the hammers strike the strings. They own key levelers and capstan wrenches. They take delight and pride in being able to understand the mechanisms of an instrument that has five to ten thousand moving parts.

Of the latter kind, there are some who are content to master their craft and exercise their talents for the pleasure and profit it brings. Then there are those who are not just artists, theorists and technicians; somehow they find the time to pass that knowledge on to others as mentors.

I have no idea if Jon Skeet is any kind of pianist. But from my email conversations with him as one of the C# team’s Most Valuable Professionals over the years, from reading his blog and from reading every word of this book at least three times, it has become clear to me that Jon is that latter kind of software developer: enthusiastic, knowledgeable, talented, curious and analytical; a teacher of others.

C# is a highly pragmatic and rapidly evolving language. Through the addition of query comprehensions, richer type inference, a compact syntax for anonymous functions, and so on, I hope that we have enabled a whole new style of programming while still staying true to the statically typed, component-oriented approach that has made C# a success.

Many of these new stylistic elements have the paradoxical quality of feeling very old (lambda expressions go back to the very foundations of computer science in the first half of the twentieth century) and yet at the same time feeling new and unfamiliar to developers used to a more modern object-oriented approach.

Jon gets all that. This book is ideal for professional developers who have a need to understand the “what” and “how” of the latest revision to C#. But it is also for those developers whose understanding is enriched by exploring the “why” of the language's design principles.

Being able to take advantage of all that new power will require some new ways of thinking about data, functions, and the relationship between them. It’s not unlike trying to play jazz after years of classical training – or, perhaps, vice versa. Either way, I am looking forward to finding out what sorts of functional compositions the next generation of C# programmers come up with. Happy composing, and thanks for choosing the key of C# to do it in.

Eric Lippert
Seattle, Washington
February 2008

Recent Book News, Part Two

Eric Lippert — Wed, 16 Jan 2008 21:32:35 GMT

Two additional quick notes about books:

I am also pleased to announce the availability of the C# 3.0 Cookbook, for which I was again lucky enough to be one of the technical reviewers. Many thanks to the authors for giving the shout-out to this blog in their front matter.

"Real" cookbooks tend to provide specific solutions to specific culinary problems; they'll tell you how to make banana bread, for instance. What I particularly like about my favourite cookbook, The Joy of Cooking, is that it does not stop there; rather, each section of recipes has an introduction that treats the subject in general. Rather than merely a dozen muffin recipes, there is an exposition on the general nature of muffins that gives some context and guidelines should you want to branch out beyond the canned recipes.

Similarly, "cookbook" style programming books tend to de-emphasize having a solid theoretical understanding of the language and frameworks, and instead present canned solutions to specific problems. Since those solutions almost certainly do not solve your exact problem, the developer must then hammer on the canned solution until it conforms to the problem at hand. That way lies cargo cult programming! Fortunately, the C# 3.0 Cookbook does a good job of not just providing a lot of good solutions to common problems, but also provides some background on the general classes of problems that it treats. This is not at all a C# 3.0 language tutorial, but it is very handy to have around when you're like "Hmm, how does one get the audit info out of a file?"

And finally, I am tickled that it has happened again. I have just heard that my last book will be translated into Chinese, of all things. Look for VSTO开发指南 coming to a Chinese bookstore some time in 2008, from 中国电子工业出版社 (China Publishing House of Electronics Industry).

Recent Book News, Part One

Eric Lippert — Wed, 09 Jan 2008 20:04:22 GMT

Good day and Happy New Year everyone, I hope you had a restful and joyous festive holiday season. I sure did.

Before I get back into my series on immutable data structures I have a few news items regarding books.

First off, I am pleased to announce the availability of C# 3.0 Design Patterns by Judith Bishop. An amusing story about this book:

I was lucky enough to be one of the technical reviewers relatively early on in the genesis of the book. (I do technical editing as a hobby; it's nice to have a hobby that brings in pocket money instead of spending it!) As often happens when the technical reviewers are done reading the book, I was asked if I would contribute a endorsing quote for the back of the book. Absolutely, I replied, it's a fine book, I would be happy to. I whipped up "C# 3.0 Design Patterns brings the frequently abstruse world of design patterns into sharp focus with pragmatic C# 3.0 implementations" in about 30 seconds and sent it off to the publisher.

First thing the next morning -- which, apropos of nothing, was my birthday -- the senior editor drops me a line to say that quote looks great, oh, by the way, how about you write us a foreword where that's the last sentence, we go to press, uh, today, but we could hold the presses until tomorrow if we need to.

Yikes!

Twenty minutes later, this is what I came up with. If it seems a little rushed, that's because it was. The foreword is the least important page of the book, including the colophon, so I'm not particularly worried.

Congratulations to Judith Bishop on her latest accomplishment in publishing, and many thanks to everyone at O'Reilly who made the editing process very pleasant indeed.

When you’re faced with a problem to solve (and frankly, who isn’t these days?) the basic strategy usually taken by we computer people is called “divide and conquer”. It goes like this:

Conceptualize the specific problem as a set of smaller sub-problems.
Solve each smaller problem.
Combine the results into a solution of the specific problem.

Reducing complex problems down to the level of twiddling the states of a few billion bits is what we do all day. But “divide and conquer” is not the only possible strategy. We can also take a more generalist approach:

Conceptualize the specific problem as a special case of a more general problem.
Somehow solve the general problem.
Adapt the solution of the general problem to the specific problem.

Design patterns are among the major tools in the toolboxes of those who espouse the generalist approach. If you look at samples from a broad spectrum of software solutions, you will find that though the specifics may vary widely, there is often an underlying structural similarity. (Searching a file system for a file with a particular attribute is in some sense structurally similar to searching an annotated parse tree for a symbol with a particular type.) Design patterns codify general solutions to common problems.

The ultimate example of the generalist approach is of course the design and implementation of programming languages themselves. As problem solving tools go, it is hard to get more general than a programming language like C#. When designing new programming languages (or new versions of old programming languages) we think about common problems that are faced every day by real developers and figure out how to create a language which solves them in a general, aesthetically pleasing and powerful way that is broadly applicable.

We want to embed the most useful and powerful abstractions so deeply into the language infrastructure that you barely even consciously register them as being there anymore. Patterns like “local variable” or “procedure call” or “while loop” are so much a part of the air we all breathe that we don’t even think of them as patterns anymore.

Furthermore, we want to make a language in which patterns which are useful but perhaps not quite so fundamental are nevertheless relatively straightforward to implement clearly and elegantly. A class in C# may be marked as “static”, or “abstract”, or “sealed”, but not as “singleton”. That was a deliberate choice of the language designers. However, implementing a singleton class in C# is still relatively easy.

The gray zone in between “clearly foundational” and “occasionally useful” is where the interesting design challenges lie. Our observations of design patterns used by real-world developers in C# (and other languages) strongly drive the design process for new versions.

Consider for example how you would implement an iterator pattern on a linked list in C# 1.0. You would end up defining an enumerator class to represent a position in the list containing a lot of boring boilerplate code (which impedes readability), and the solution would not be very reusable. The notion of “enumerate a set of things” is sufficiently applicable to a wide variety of problems that it met the bar for inclusion as a first class language concept. In C# 2.0 with its “yield return” statement the compiler can generate all the boring code for you, and the generic type system makes iterating over a set of things typesafe no matter what the “things” are.

All of this is a long way to say just why it is that I am so very excited about Language Integrated Query (LINQ) in C# 3.0. We believed that iterating over collections of things was a great start, but that we could do so much more. Sorting, filtering, grouping, joining, projecting and transforming data are also fundamental operations which are useful in pretty much every domain. Whether you are writing a ray tracer, a compiler, an XML reader or an online banking security system, odds are good that you are going to need to manipulate collections of something in a rich way.

By moving these concepts out of domain-specific object models and into a general-purpose programming language hopefully we solve those more general problems. We additionally hope though that by adding C# 3.0’s query expressions, lambda expressions, extension methods, initializer expressions, expression trees, and so on to the already rich set of C# 2.0 and 1.0 features, we make it easier to elegantly implement all sorts of other useful design patterns.

And that is also why I am excited about this book; C# 3.0 Design Patterns brings the frequently abstruse world of design patterns into sharp focus with pragmatic C# 3.0 implementations. I look forward to seeing where developers can go with these tools and this language, and what useful patterns we can build into the infrastructures of future languages.

Eric Lippert
Seattle, Washington
November 30, 2007

Visual Studio Tools For Office: Using Visual Basic 2005 with Excel, Work, Outlook and InfoPath

Eric Lippert — Mon, 01 May 2006 19:47:00 GMT

Eric Carter and I are excited to announce that the Visual Basic edition of our book about Visual Studio Tools for Office is now available. I'd like to give a big thank-you to everyone who put their time, energy and enthusiasm behind this project, particularly my co-author (who, as always, did most of the heavy lifting.)

Visual Basic and Office programmability have gone together for a long time now and it was very important to us that we build a product that worked well for Office VBA programmers who want to move into the rich .NET world. It was therefore equally important that our book cover the particular needs of Visual Basic programmers. Sorting out whether we would have one book cover both C# and Visual Basic, or two books, and which one to do first was an agonizing process, but ultimately I think we made the right choices, and I'm thrilled with the result.

My only regret is that we couldn't make the title longer. I wanted it to be "Teach Yourself How To Build Professional Real-World Enterprise Solutions With Microsoft Visual Studio .NET 2005 Tools For Microsoft Office System 2003 Using Microsoft Visual Basic 2006 With Microsoft Excel, Microsoft Word, Microsoft Outlook and Microsoft InfoPath In Twenty-One Days In A Nutshell". Apparently that would have involved making the cover larger or infringing on a trademark or something, and it just wasn't feasible.

See Eric's recent blog post for more details about the book and where to download the code samples.

Book Signing at the PDC

Eric Lippert — Wed, 07 Sep 2005 18:25:00 GMT

It's a week until PDC! Very exciting. Unfortunately I'm not going this year but my coauthor and erstwhile lead Eric Carter will be there, along with Misha Shneerson and Andrew Whitechapel. He'll be talking about VSTO 2.0 (the about-to-be-released product) and you can also see a sneak preview of early VSTO 3.0 work running against Office 12. All the VSTO session details are on Eric's blog.

Eric will also be signing copies of our book. We haven't even seen copies yet! The ink will probably still be wet at the PDC.

And of course, Anders will be talking about the new C# 3.0 features coming up, which is good, because then I'll be able to blog about them while we're working on them.

Excitement, adventure, really wild stuff. I'll see if I can get the PDC gig next time. This blogging stuff is nice, but it's even better to be able to meet real customers face-to-face.

I'm So Prolix

Eric Lippert — Tue, 07 Jun 2005 02:27:00 GMT

I mentioned earlier today that my latest book project has gone to copyediting. To forestall a few questions:

Are you the sole author?

Good heavens no. Most of the heavy lifting was done by my colleague Eric Carter. I’m just along to make sure that his love affair with the comma doesn’t get totally out of control. And I wrote a chapter or two here and there.

What’s the deal with writing a technical book?

I was going to write a long article about that, but fortunately Eric Gunnerson did me a huge favour by writing it for me. I agree 100% with everything Eric says in his article.

If you are in it for the money and not the fame, I recommend becoming an expert in some technology and becoming a technical reviewer/editor. Though it’s less money, its way more dollars per hour unless you’re planning on writing a best seller. O’Reilly, APress and McGraw-Hill have given me good tech editing gigs over the years. It’s nice to have a hobby that pays for all your other hobbies.

What’s it about?

It’s a Tom Clancy-style page turner with lots of beautiful, deadly women, men who carry powerful handguns, and a plot to take over the world by improving knowledge worker productivity through adding managed customizations and add-ins behind Word, Excel, Outlook and Infopath.

What’s the title?

Well, I wanted to call it "Programming Customized Microsoft Word, Microsoft Excel, Microsoft Outlook and Microsoft InfoPath Customizations and Add-Ins With Microsoft Visual Studio .NET 2005 Tools For the Microsoft Office 2003 System In Microsoft Visual C# .NET" because haven’t you heard, long book titles are totally in this year. Sadly, my coauthor and our editors cut that down to "Visual Studio Tools For Office Using C# with Word, Excel, Outlook and InfoPath". Not a single ".NET" or "Microsoft" in there!

Check out this swanky cover design:

Where can I get a copy?

If you happen to be at TechEd, Addison-Wesley is giving out free samples, or you can download the sample in PDF form. (Note that, as it says in the PDF, this is a straight-from-the-devs drop of the text. The table of contents is in the wrong order, we probably use "which" where we should use "that", and so on.)

The book should be available in stores and at the Los Angeles Pro Dev Con in early September.

I’m just glad that most of the authors’ end of the work is done. That was a whole lot of weekends.

Books, Books, Books

Eric Lippert — Fri, 27 May 2005 03:23:00 GMT

It looks like the intricacies of higher-dimensional geometry will have to wait another week; I am incredibly heads-down putting the finishing touches on VSTO and the book that Eric Carter and I are writing on VSTO. We're due to have it ready for copy-editing and indexing by the end of the month, so I know what I'm going to be doing this weekend, and its not barbecuing or sailing.

Ah well, plenty of time for that later.

Speaking of books, Joel was kind enough to do me the honour of choosing How Many Microsoft Employees Does It Take To Change A Light Bulb? as one of his selections for his new blogs-printed-out-on-dead-trees book The Best Software Writing. TBSW will also feature articles by Raymond and many other smart, funny, controversial and thought-provoking technical bloggers and will be available to purchase on June 20th.

It was hard to resist the temptation to read the galleys of everyone else's articles, but somehow I managed -- I'm totally looking forward to seeing what all Joel has chosen.

How many Microsoft employees does it take to change a lightbulb?

Eric Lippert — Tue, 28 Oct 2003 23:41:00 GMT

UPDATE: This article was featured in The Best Software Writing I. Thanks Joel!

Joe Bork has written a great article explaining some of the decisions that go into whether a bug is fixed or not. This means that I can cross that one off my list of potential future entries. Thanks Joe!

But while I'm at it, I'd like to expand a little on what Joe said.His comments generalize to more than just bug fixes. A bug fix is one kind of change to the behaviour of the product, and all changes have similar costs and go through a similar process.

Back when I was actually adding features to the script engines on a regular basis, people would send me mail asking me to implement some new feature.Usually the feature was a "one-off" -- a feature that solved their particular problem. Like, "I need to call ChangeLightBulbWindowHandleEx, but there is no ActiveX control that does so and you can't call Win32 APIs directly from script, can you add a ChangeLightBulbWindowHandleEx method to the VBScript built-in functions? It would only be like five lines of code!"

I'd always tell these people the same thing -- if it is only five lines of code then go write your own ActiveX object! Because yes, you are absolutely right -- it would take me approximately five minutes to add that feature to the VBScript runtime library. But how many Microsoft employees does it actually take to change a lightbulb?

One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.
One program manager to write the specification.
One localization expert to review the specification for localizability issues.
One usability expert to review the specification for accessibility and usability issues.
At least one dev, tester and PM to brainstorm security vulnerabilities.
One PM to add the security model to the specification.
One tester to write the test plan.
One test lead to update the test schedule.
One tester to write the test cases and add them to the nightly automation.
Three or four testers to participate in an ad hoc bug bash.
One technical writer to write the documentation.
One technical reviewer to proofread the documentation.
One copy editor to proofread the documentation.
One documentation manager to integrate the new documentation into the existing body of text, update tables of contents, indexes, etc.
Twenty-five translators to translate the documentation and error messages into all the languages supported by Windows.The managers for the translators live in Ireland (European languages) and Japan (Asian languages), which are both severely time-shifted from Redmond, so dealing with them can be a fairly complex logistical problem.
A team of senior managers to coordinate all these people, write the cheques, and justify the costs to their Vice President.

None of these take very long individually, but they add up, and this is for a simple feature.You'll note that I haven't added all the things that Joe talks about, like what if there is a bug in those five lines of code? That initial five minutes of dev time translates into many person-weeks of work and enormous costs, all to save one person a few minutes of whipping up a one-off VB6 control that does what they want.Sorry, but that makes no business sense whatsoever. At Microsoft we try very, very hard to not release half-baked software. Getting software right -- by, among other things, ensuring that a legally blind Catalan-speaking Spaniard can easily use the feature without worrying about introducing a new security vulnerability -- is rather expensive! But we have to get it right because when we ship a new version of the script engines, hundreds of millions of people will exercise that code, and tens of millions will program against it.

Any new feature which does not serve a large percentage of those users is essentially stealing valuable resources that could be spent implementing features, fixing bugs or looking for security vulnerabilities that DO impact the lives of millions of people.

UPDATE: KC Lemson and Raymond Chen and Chris Pratley have opinions on this as well.

Dead Trees vs. Bits

Eric Lippert — Thu, 16 Oct 2003 20:03:00 GMT

Speaking of books, people keep telling me and Peter and Raymond that we should write books based on our blogs.

Well, I probably am going to write another book this winter, but it will have pretty much nothing to do with the stuff in this blog. The natures of a blog and a book are very different. Let me list some differences:

Creative control

I can blog what I want, when I want, at what length I want, and can say whatever I want. In particular, I like to ramble on about the scripting technologies -- which, though they are widely used, are clearly a 20th century technology. .NET is the future. A book has to be on a specific topic, finished by a specific time, at a specific length. A book has to be about a current technology topic and have a clear beginning-middle-end structure. Books both allow editing and require editing. Blogs resist editing.

Business model

Books work on the ink-on-dead-trees business model. Weblogs work on the "bits are free" business model. If I went to a publisher and said "I want to write a short but rambling book about random, arcane, trivial details of the history and internals of a 1996 technology that is presently being made increasingly irrelevant and outmoded by .NET" then the publisher would say "thanks, but no thanks". People buy computer books because they have a problem that needs solving, not because they enjoy learning my opinions about proper Hungarian usage.

Books MUST make money to exist. My aim for this blog isn't to make money, it is to dump my vast collection of arcane into some googlable location.

Scope of readership

My blog is available to everyone in the world with a web browser, and given the subject matter, that's everyone I want to reach. Books are available to only the very small number of people who actually buy the book. If you like my book and you want your friend in Europe to read it, you can't just send them a link. Again, books cost money and that limits the potential readership.

Permanence

My book is no longer available because of circumstances beyond my control. Now, Microsoft isn't going to go out of business, but if they did, I could just move the blog file to another machine in about five minutes and be back up and running. This blog will be archived and therefore part of the permanent searchable record of knowledge on the internet. The copies of my book in the Library of Congress (and whatever the British equivalent is) aren't going to help a whole lot of devs.

And finally, apropos of nothing in particular, this is hilarious: http://mama.indstate.edu/users/bones/WhyIHateWebLogs.html, mostly because it is so self-referential. One wonders what category the author himself falls into. Thank goodness my blog falls under one of his acceptable uses of blogs! I don' t know how I could continue to face myself in the mirror every day without this guy's approval.