OK, but what advantages does it have over not prefixing the interface name  
with an 'I'?  I'm assuming that there must be some perceived advantage  
otherwise it would be completely pointless.

Dan.

IMO its one of the silliest ideas ever to infect programming.

The problem is that it completely destroys information hiding by forcing
implementation details to be included as part of all variable and
function names. Change the internal representation of a variable or the
return value of a function or method and you have to change its name and
then churn through all your source, changing all references to the name.
Stupid. It can just about be made to work with ANSI C, but it is
completely at odds with any language that supports overloading.

The best explanation for its existence is that M$ came up with the idea
to paper over deficiencies in its early compilers' type checking. If you
use "Hungarian notation' in its full rigor *you* are the type checker,
not the compiler. This seems like a perverse role reversal to me.

For sensible ideas about naming, source layout, and programming in
general you can't do much better than get a copy of "The Practice of
Programming" by Brian Kernighan and Rob Pike. Its ideas are applicable
to just about any programming language and it contains reasonably
substantial examples in C, C++ and Java to prove it.

A point of clarification, this is *NOT* Hungarian notation. This is an
example of type-based naming, which, Micro$oft incorrectly labelled as
Hungarian.

True Hungarian naming defines prefixes for names based on what the item
represents. Type-based naming defines prefixes based on the data type in the
programming language.

So for example if we had a variable that contained the height of a screen
whose data type in C were unsigned long, then possible names in the two
conventions would be:

 Hungarian - hgtScreen
 Type naming - ulScreenHeight

The problem is that there is little value in type-based naming. Imagine if
you also had an unsigned long screen color. If you tried to assign this to
the above variable in type based-naming it might look like:

 ulScreenHeight = ulScreenColor;

The statement makes no logical sense, but the type-based naming prefix
didn't tell you anything. Compare thiw with Hungarian:

 hgtScreen = clrScreen;

One of the main problems with type-based naming is that types can change.
For example in Windoze there is wParam which ceased being a word ages ago,
but they couldn't change the name without breaking users.

Hungarian is not nearly as usefull in an OO language, but it is not as bad
as you were lead to believe from M$'s misuse of the term.

The I convention is relatively harmless, but offers little, if any, benefit.
In addition to the origins in COM as others have mentioned, Eclipse also
uses this convention. According to their convention guidelines, "This
convention aids code readability by making interface names more readily
recognizable." I don't find it necessary myself.

One reason it is used is to simplify naming of interfaces and concrete
implementations of that interface so you can have IFoo interface and the
concrete implementation could be called just Foo. I'll leave it up to you to
decide if this is a good thing or not.

I'd say the more important effect is that it prevents code from reading
nicely.  A piece of code is written once; read long after you have
retired.

Agreed, there are too many examples of people doing things, like this,  
because somebody told them it was a good idea.  The justification usually  
sounds something like "because it's considered good practice...".  By  
who?  And more importantly, why?  If a developer can't explain why  
something is a good idea, perhaps they shouldn't be doing it in the first  
place?  This is kind of the point I was trying to get to in the "Design  
Question" thread the other day.

Dan.