On internals

November 13th, 2008

I hate internals and privates and lack of extension points. Really! Many times I’ve wondered ‘what’s wrong with these people that hide all this stuff from me? are they concerned I wouldn’t know how to use it?’

Being on the other side now, and trying to slowly change the culture, I have to say that I understand why MS is so reluctant to make things more open by default. And all comes down to the fact that we don’t make breaking changes.

If we were to open a poll and ask developers what they would prefer: more open and extensible API vs no breaking changes, I’d guess you would go with open/extensible. And later act surprised when a new version of the framework broke your app, forced you to make changes on your code in order to get it compiling, and so on.

That doesn’t mean that openness is forbidden and extension points are evil. Just that we think very – and I mean _very_ – carefully about those. Once we ship it, we can’t remove it. We can’t change it. Ever!

That being said, I think we are going slowly but surely in the direction of open-closed principle and composition over inheritance, at least on my team, and this is enough to make me happy (for now).

Categories: MEF, MS | Top Of Page | 9 Comments » |

9 Responses to “On internals”

Eric Nicholson Says:

“And all comes down to the fact that we don’t make changing breaks.”

That’s a Freudian slip if I’ve ever heard one…


hammett Says:

Fixed. It’s been a long long day.. :-)

Vladan Strigo Says:

In the last couple of frustrations with MS MVC internals, I’ve also come to one more conclusion.

If the team is set up right, internals make you rethink design if it needs to be rethought.

When I find an internal, sealed or something that I need and cannot use, I contact Phil, to Phil this says that either they don’t have the correct extension point, that there exists a scenario of usage they did not see, and some other bits… put simply, gives him a feedback on design.

If it was other way around, everybody would extend whenever, whatever, and the design of framework would not have a chance to evolve, simply because most feedback would come from the product team and not from the users themselves.

Now, I REALLY don’t like internals (I am still on this side of the fence), but to some extent I can *try* to understand why they are there :)


josh Says:

huh, echos of Ayende in your opening words. I too am in the position of providing a public SDK and needing to keep some things internal or even private. It can be really frustrating to be limited to no making breaking changes. There are times when a simple change would make life better for everyone, but it would break compatibility. Customer and management would not like that. Oh well, its a necessary evil sometimes.

James Curran Says:

>>And later act surprised when a new version of the framework broke your app, forced you to make changes on your code in order to get it compiling,

Haacked Says:

…Or worse, an upgrade forces you to hit up the vendor of the library only to find out they went out of business so now you have to spend a huge amount of time to rewrite the library, which you have no real expertise in. ;)

Sometimes we hide things because we’re not ready to show them. IBuildManager in MVC is an example. We know it’s not a complete interface and it’s not in the right place. But it’s good enough for now. By keeping it internal now, we can complete it later when MVC takes a dependency on a later version of the core framework.

At the same time, I do hope (and see shifts) in this whole non-breaking change policy. Hopefully we’ll see something along the lines of every X framework releases, we can make targetted breaking changes. ;)

James Curran Says:

Hmmm…. It seems the important part of my message got lost.

The bigger reason for backward compatibility, is that if a new Framework (.NET CLR for instance) or OS were to break existing apps, then the customers of those apps would need to acquire and install the corrected version, which the vendor would be expected to produce & distribute for free. That’s the type thing that get people to start suing Microsoft.

Brian DeMarzo Says:

I’d rather have an open framework that has breaking changes in new versions than a closed framework.

After all, aren’t we expected to test our code extensively before assuming it runs on a new version of any dependencies?

Bryan Watts Says:

My intestines are internal. They are part of what allow me to function, but also an implementation detail.

The ends of my intestines, while they could be hooked up to other things besides my mouth and colon, are not meant for that.

Leave a Reply