If you can't decide, give the user more options -- not!

I find my self in the middle of lots
of sticky API design issues. Usually we have a couple of pretty clear
options with well known pros and cons. Sometimes the battles get pretty heated
between people arguing for one option or another and some well meaning PM
suggests “let’s just do them both”… It is hard to seem reasonable and argue with
that - after all both sides got what they wanted right? Maybe, but the poor user is in a net
worse place. If we’d just decide on
an option and get 100% behind it we could make the world SOO much better. There would be net fewer types and
methods in the system and the ones we’d have would be better!prefix = o ns = "urn:schemas-microsoft-com:office:office"
/>

I had another one of those issues
come up today. A team coming in for
API reviews had a base class, let’s call it “Foo” (so as to not spoil any of the
fun from the PDC) and an interface called “IFoo” that represented exactly the
same contract. So I ask why they
have both. Well, it seems that some
clients wanted and interface and some wanted a base class. In other words, they couldn’t
decide. So I ask, when you expose
methods that take with Foo’s what are you suppose to use? Foo or IFoo? When
would I use one over the other? Do
your methods take Foo and IFoo? We
had the same problem with Component and IComponent and eventually had to add
specific test cases to make sure IComponent kept working because most everything
derived from Component, it became the defacto standard. Having IComponent there to support a
niche scenario adds net complexity to the system. I think the same is true for today’s
Foo\IFoo case. In the end we
decided to the vast majority of scenarios were satisfied by just using the Foo
base class.

I think the world got every so
slightly better today because we took away an option…. Score another point for
addition through subtraction.