As Raymond says, most development teams face some kind of “tax” in their day-to-day work. Taxes are things that a programmer has to do or take into consideration that are usually: a) not specifically assigned for him to do, b) not specifically accounted for in his schedule, and c) not specifically very much fun. The first example Raymond used was power management — something that pretty much every Windows application should take into account but which a very great many applications don’t.

One of the wonderful things about working on a compiler is that, by and large, you escape most of the more egregious taxes. You don’t have any UI, you are pretty task-focused, you don’t deal with many other components in the system, and everyone expects you to consume a lot of resources (although not so many that the machine is brought to its knees). So lots and lots of things that other programmers have to worry about, we don’t. It’s great!

Wait, though, did I say that we didn’t have any UI? Well, technically, that’s true — the core compiler group takes text in and outputs bits on disk. But while the compiler doesn’t really have a UI itself, we don’t get off the hook completely because there’s lots and lots of UI that gets built around the compiler to help people, you know, write programs and stuff. And the language and compiler design cannot be entirely ignorant of that fact, nor can it bear no responsibility for how easy or hard it is to write that UI.

We’re at the point now with LINQ where we’re really starting to take a serious look beyond the language features, cool as they are, and pondering how these features are going to integrate with the UI. (It’s not like we haven’t thought about it at all, we have, but now we’re really taking a look at things end-to-end.) And so we started by coming up with a “language UI taxes” list that I’m shocked we haven’t put into a more concrete form until now. The various taxes that a language feature is going to have to pay include, but are not limited to:

• The code model
• Edit and Continue
• Stepping in the debugger
• Expression evaluation in the debugger (for things like the watch window, immediate window, etc.)
• CodeDOM
• Intellisense
• Object Browser/Goto Definition
• Class View
• Code spit (i.e. things like automatically pasted in overrides and event handlers)
• Tooltips
• Rename symbol
• Error correction
• The dropdowns at the top of the editor window
• The attribute editor
• Dynamic help
• Pretty listing
• Code colorization
• Editor outlining
• Refactoring
• Snippets
• XML Documentation
• Class Designer

In many ways, the real cost of a language feature isn’t in the feature itself, it’s in the myriad of UI taxes that must be paid on any particular feature. Optimal tax planning is the secret to a good schedule these days…