The Framework Apologist

Paul Stovell reacted to a presentation by Scott Hanselman and Keith Pleas and then Scott Hanselman followed up with his views – or rather an explaination of his position. It is interesting to stand on the sidelines and follow this conversation – especially since there was a lot of traffic on the internal Readify Tech mailing list about it prior to Paul making his original post.

As someone who has had to both design frameworks and consume frameworks developed by other people, I can kind of see both points of view. One of the things that I don’t think has really been brought to the table is the difference between building a framework for every single .NET developer on the planet, and building a framework for just your team (and there is a grey area in the middle there when talking about enterprise frameworks).

Building a framework for every single .NET developer on the planet is hard, you are bound to have someone who disagrees with your approach and you _could_ just mark everything as public virtual (so that you can not only call it, but change it). Some languages work this way.

The drawback of that approach is that you may expose something that is ill thought-out, and then someone comes along and relies on that particular internal implementation detail. You then have two choices – you either break them, or you fork the code. Forking code to support specific customers is really not an option for Microsoft – yet breaking a production system as the result of a patch is not going to make them popular.

The end result is that you need to hide some implementation detail to play it safe and not piss people off, but you need to be as open as possible to allow developers to do what they need to do. I hate to say it, but this is a classic design problem. If we look at the sheer volume of frameworks that Microsoft produce (WPF, WCF, WF, .NET Base Class Library, Visual Studio, Windows Forms, ADO.NET, ASP.NET) – is it any real surprise that they get it wrong some of the time.

I think it is dangerous to assume that we can apply small team framework building philosophies to commercial and foundational programming frameworks. If the ASP.NET team had opened up the session state management API in .NET 1.0 I suspect that they wouldn’t have been able to do as good a job as they did in .NET 2.0. In the end it comes down to a balance between not shipping a perfect open API that isn’t going to bite you back, or shipping a perfect slightly less open API which isn’t going to bite you back.

One thing is for sure, when code bites back, it bites hard.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s