+972 52-548-6969
Consenting Adults
David Kean has an interesting post here: "I can't believe Microsoft didn't make [Enter API Name Here] public"
In particular, he mentions this aging argument:
Developing good APIs is extremely difficult, especially the first time around. When we get things wrong (and we do get things wrong), trying to maintain backwards compatibility often stifles innovation as we try to correct these scenarios. Unfortunately, unlike others, we don't have the luxury to make only 95% of our new versions backwards compatible with our previous versions.
I have a lot of problems with this statement. Chief among them is the treating the users as people who should be cuddled. Actually, I don't really have a problem with cuddling, the real problem is that this is literally putting road blocks for progress.
The Microsoft backward compatibility strategy is a major reason why the default approach is to close down everything. Now, it is not as if there isn't a well defined way of saying: Touch that on your responsibility. This is quite pervasive, actually:
This API supports the .NET Framework infrastructure and is not intended to be used directly from your code.
But I think that this isn't actually the problem. The problem is that the rules that Microsoft has chosen to accept are broken. In that type of game, you are always losing. The only thing that you can do is to change the rate in which you are losing at.
Change the rules, treat the users as consenting adults, and you'll be able to do so much more, because the task ahead of you would be so much simpler.
Comments
I think you mean "coddle" rather than "cuddle".
I suspect you are right, Paul, but perhaps "cuddle" is a cunning and ironic lead-in to future post on what Microsoft is doing to some of it's "consenting adult" customers via poor guidance and near prohibitive licensing costs?
I think I've said it before but I think the problem stems from MS throwing everything into the .net framework and developers that don't look into anything thats not in the framework.
So now the framework has 2 GUI libraries (winforms and WPF) and neither can be significantly refactored because it would break old code.
If it was in a separate (distributable) library they could break anything they want between versions.
Have you consider what would happen if they actually followed your advice?
Do you really want to rewrite major parts of your application every time a new version comes out?
When a new version comes out... aren't existing apps already targeting a specific (major.minor) version of the .NET runtimes?
Ayende,
I posted an article on why I think public virtual ubiquity would fail.
jeffhandley.com/.../...al-ubiquity-would-fail.aspx
-Jeff
Ayende i dont think that consenting adults has anything to do corporations trying to earn money. I think that exact opposite would happen - no progress at all. Corporations would be so scary to switch to new version of framework that there would be no investments to projects based on future versions. I almost completelly agree with Miscoroft policy in this case.
@naraga, yeah, I hit on that in my post too.
Breaking stuff left and right is good for you, because you control the whole stack, and the stuff you don't control (the framework) is generally rock-solid and DOES NOT CHANGE. How much did you fume when MS broke one tiny little edge case in their SP just couple months ago? What would you say if more widely used things became "better designed" (from the point of view of existing code -- broken) every year or two? And don't even get me started on "I'll just target version xx.yy forever and ever" -- you might do that. but the vendor of the library you desperately need will decide to move on. What will you do then? Having to make changes to the application just to keep up with the moving target that is the framework is expensive. And from a general framework user's point of view it is an expense that he does not want. In short -- backwards compatibility is a BIG DEAL.
One of the reasons I no longer use PHP is because when a new version is released it will often break something somewhere in your code - backward compatability is in my opinion a big plus for .net
@Paul
Argh, I hadn't thought of the fact that it might be a typo. I was just loving the image created by "Actually, I don't really have a problem with cuddling".
Your post is a typical response from an open source developer who can say "that's in the trunk, get the latest daily build". They can't do that. Not now, not ever. What they release as v1, v2, v3 etc., is THE version 1, 2, 3 etc. There's nothing that can change that afterwards, as things were already released and millions of developers DEPEND on the state of the API in v1, 2, 3 etc.
They therefore have to make absolutely sure that everything is in the api and that everything works. Max hit the nail on the head, backwards compatibility is a big BIG deal: the best thing that can happen to software engineers is that their software simply WORKS on vNext, and they get all the new stuff for free. You refer to 'zero friction' software over and over, well... frameworks which are backwards compatible are zero friction software: the developer can FORGET about changes in the framework from v1.abc to v1.abcd, and if he has to get a new daily build from subversion from some server. He can simply build the code he is supposed to write (the code is payed to write!) and focus ALL his energy on that.
That's why backwards comparability is very very important. So much so, that it's likely one of the most important aspects of a framework.
Breaking backwards compatibility is just not an option for a framework with millions of consumers.
However... I believe Microsoft does have one problem regarding how it builds its frameworks: it often tries to squeeze in whizz-bang one-off features. They look good in demos but that sort of development is simply not conducive to achieving SOC and OCP.
Here's one example. There's some fancy auto-wiring for transaction enlistment in ASP.Net. It actually works because ASP.Net sets an undocumented AppDomain-level user-data variable that the System.Data internals know to go read. This kind of private wormhole is ridiculous in the extreme!
One might argue that Microsoft should be trying to enable everyone to build whizz-bang features simply by virtue of building its own in open ways using their own extensibility APIs.
Unfortunately, the problem is that it just costs more to build open interfaces that support first-class extensibility. Also, it's hard to get the extensibility story right the first time. Every API is a promise to maintain and support some abstraction pretty much indefinitely no matter how broken it might be. Extensible systems tend to have a greater (hence more costly) surface area in that regard. So in the end it's much easier and cheaper to just build relatively closed interfaces.
After all, enterprises will just build their own abstractions on top of whatever is offered.
So it's not laziness, nor idleness, just pragmatic and conservative policies backed by some rather sound business and technical reasons...
You wouldn't like it if you had to re-examine all of the assumptions in your apps after each major framework release would you?
(That said, they could do to raise the level of abstraction a tad. I've been burned by some issues involving the coupling policy and mechanism in framework classes. Sometimes the framework is too framework-y whereas it should be more library-y...)
@ Ayende :
Does your NHibernate Query Generator work with NHibernate version 2.x ??
I succeded to run your generator v.1.9 as custom tool, but it looks like there are some changes in NHibernate 2.x namespaces, generated code does not compile with referenced Nhibernate 2.x
You need to run with the trunk version
You seem to be missing David Kean point. They don't "choose" to be backward compatible. They literally do not have that option. You may want to be treated like an adult.
However, most large corporations insist on being coddled. And if a new version of the framework/OS causes their application to stop working, they start screaming about lawsuits and "abuse of monopoly power".
Based on personal experience, what you are suggesting does not work.
For the last 5 or so years, FxCop has a public API for writing custom rules. It is not documented, not supported and we've repeatedly told customers that it was very likely to change in future versions. Regardless of this, people would personally email me upset that we broke their custom rules when we did change the API. Writing custom rules can be complicated as you need to understand IL to really get anything out of them, so these aren't just mort developers, these are advanced users like you and Jeremy.
If this happens with an API that isn't even documentated and doesn't ship with the Framework, can you imagine what would happen when these APIs start appearing in MSDN and IntelliSense? Not only would the advanced users start using them, but everyone would. Mort goes with whatever works - if a class looks like it does the right thing, then he's going to use it.
This would completely prevent us from ever innovating.
I would say that it prevents you from doing many useful work now (I refuse to use that i word).
But I have a very simple answer for people complaining, it can't really translate to English, but you can think about it as: there be dragons, deal with it.
That should be an acceptable answer. The moment that it become one, now we are talking.
Yes, but if that was an acceptable answer, then we wouldn't have any reason to shim applications in Vista when they did the wrong thing (we would obviously still shim when we did break compatibility). Unfortunately, press, CEO’s, and users don’t see it as the applications at fault when an application stops working; Microsoft and Windows is instead blamed. Compatibility is a proven adoption blocker, this is actually the exact reason why we’ve been adding functionality in service packs – as they are not seen as a new version and therefore large corporations don’t have a problem rolling them out.
I think the better way to approach this would be in a couple of ways:
Release previews and CTPs early. I don’t mean Betas, once something has shipped in a beta, it’s already too late to change. This will allow customers, like yourself, to give us feedback early about the kind of extension points you think are missing. MEF and MVC are examples where we doing well in this space. More teams should and will follow.
Release source without restrictions. This allows customers to simply copy and paste internal API that they think should be public.
Reduce coupling. My team is responsible for enforcing this in the Framework as a whole (ie for example, we’re trying to remove ASP.NET's current dependency on WinForms - no joke). However, we have no control on how teams do this on an assembly by assembly basis. This will mean that if ASP.NET wants to turn a special switch in System.Data, then they should to do this via the same supported mechanism that customers would – no more InternalsVisibleTo. As more teams adopt MEF, hopefully most teams will get this for free.
Thoughts?
Here's a free lesson for Microsoft:
if you make a business decision to do things a certain way, then fine. But don't defend it by saying something like "we have no option to do it differently", defend it by saying "this is the way we do business, and these are the reasons...". This is the honest and open approach. Whatever you do, you can't please everybody, so stick to your guns and be prepared for the consequences.
To whine about being locked in by the expectations of the press, CEO's etc is a bit weak IMO.
I should comment that my above position is my own personal opinion and although I work for Microsoft, may or may not represent Microsoft's view as a whole.
My point was that if we don't do this - then people don't upgrade. No compatibility == no money. Simple as that.
No compatibility turns to switching camps (in a previous job that was VB.NET was a breaking change to VB6) - so the company decided to go Java.
A lot of people, who were complaining about breaking changes were then out of job on top of it.
Three lessons here:
As a developer stay up to date on technology and don't whine when you fall behind or don't understand it and when you know something 'big' is coming - be prepared.
As a developer and CIO, be prepared for breaking changes when they do come and have a plan in place to deal with them.
As a product company (in this case Microsoft): keep breaking changes to a minimum because you may loose large profits due to companies being frustrated at being forced to make a change and in their change abandon you all together.
I won't say the name of the company, but I know they gave Microsoft a LOT of money (probably well into the several millions per year).
Comment preview