How do the various idioms of ExtremeProgramming apply differently to the world of COM, if at all?

----

From an email to the Microsoft DCOM mailing list:

<snip>
 I'm very interested in XP and would love to know how you resolve some of the
 issues that I think might be a problem.

 Refactoring vs Immutable COM interfaces.  It seems to me that COM interfaces
 would be constantly changing under XP, yet COM requires that you continue to
 implement all previous versions of an interface.  How do you avoid interface
 proliferation?

 Doing the simplest thing that could possibly work vs defensive programming.
 Defensive programming is often anything but simple: wrapping COM methods in
 try-catch blocks.  Extensive use of 'strong' pointers to manage resources
 etc.  How do the XPerts out there resolve this conflict?  Coding standards?

 Thanks for your time,
 Nick
</snip>

--DrewMarsh

----
'''Refactoring vs Immutable COM interfaces'''

There really isn't any difference between COM interfaces and any other API you ship: after you ship it you will have to pay a high price if you want to change it. It is important to note that this only applies to ''published'' interfaces. If you are the only client of a COM interface that you are developing then you are free to change it as much and as you like as often as you like. I know that violates the "rules" but it's okay -- I won't tell on you.

If the customer expects to get value out of shipping COM interfaces then there ought to be lots of user stories about the interfaces and they ought to be implemented early -- those are business decisions though. It will be the customer who decides how many interfaces there will be and what they will do. 

----
'''Doing the simplest thing that could possibly work vs defensive programming'''

What could go wrong? Is there a test for that? If you need robustness then you must test for robustness and do the simplest thing that makes the test pass. Remember in XP you DoTheSimplestThingThatCouldPossiblyWork first, then you get it to work, and then you refactor it to maximize simplicity. What you end up with is a very simple thing that does actually work.

You can put any quality into your product you want to so long as your customer writes a story that demands it and you can write tests for it.

----

See: ExtremeProgramming, ComponentObjectModel