http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660No 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: 1. 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. 2. As a developer and CIO, be prepared for breaking changes when they do come and have a plan in place to deal with them. 3. 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). http://ayende.com/3744/consenting-adults#comment22http://ayende.com/3744/consenting-adults#comment22Thu, 11 Dec 2008 18:36:44 GMTI 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. > To whine about being locked in by the expectations of the press, CEO's etc is a bit weak IMO. My point was that if we don't do this - then people don't upgrade. No compatibility == no money. Simple as that. http://ayende.com/3744/consenting-adults#comment21http://ayende.com/3744/consenting-adults#comment21Thu, 11 Dec 2008 02:39:54 GMTHere'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. http://ayende.com/3744/consenting-adults#comment20http://ayende.com/3744/consenting-adults#comment20Thu, 11 Dec 2008 02:07:42 GMTYes, 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: 1. 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. 2. Release source without restrictions. This allows customers to simply copy and paste internal API that they think should be public. 3. 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? http://ayende.com/3744/consenting-adults#comment19http://ayende.com/3744/consenting-adults#comment19Thu, 11 Dec 2008 00:12:20 GMTI 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. http://ayende.com/3744/consenting-adults#comment18http://ayende.com/3744/consenting-adults#comment18Wed, 10 Dec 2008 23:51:20 GMTBased 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. http://ayende.com/3744/consenting-adults#comment17http://ayende.com/3744/consenting-adults#comment17Wed, 10 Dec 2008 22:26:31 GMTYou 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". http://ayende.com/3744/consenting-adults#comment16http://ayende.com/3744/consenting-adults#comment16Wed, 10 Dec 2008 18:16:29 GMTYou need to run with the trunk version http://ayende.com/3744/consenting-adults#comment15http://ayende.com/3744/consenting-adults#comment15Wed, 10 Dec 2008 14:18:09 GMT@ 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 http://ayende.com/3744/consenting-adults#comment14http://ayende.com/3744/consenting-adults#comment14Wed, 10 Dec 2008 13:00:53 GMTBreaking 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...) http://ayende.com/3744/consenting-adults#comment13http://ayende.com/3744/consenting-adults#comment13Wed, 10 Dec 2008 09:59:28 GMTYour 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. http://ayende.com/3744/consenting-adults#comment12http://ayende.com/3744/consenting-adults#comment12Wed, 10 Dec 2008 09:10:41 GMT@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". http://ayende.com/3744/consenting-adults#comment11http://ayende.com/3744/consenting-adults#comment11Wed, 10 Dec 2008 08:54:25 GMTOne 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 http://ayende.com/3744/consenting-adults#comment10http://ayende.com/3744/consenting-adults#comment10Wed, 10 Dec 2008 08:46:46 GMTBreaking 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. http://ayende.com/3744/consenting-adults#comment9http://ayende.com/3744/consenting-adults#comment9Wed, 10 Dec 2008 08:10:05 GMT@naraga, yeah, I hit on that in my post too. http://ayende.com/3744/consenting-adults#comment8http://ayende.com/3744/consenting-adults#comment8Wed, 10 Dec 2008 07:46:04 GMTAyende 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. http://ayende.com/3744/consenting-adults#comment7http://ayende.com/3744/consenting-adults#comment7Wed, 10 Dec 2008 07:37:50 GMTAyende, I posted an article on why I think public virtual ubiquity would fail. [jeffhandley.com/.../...al-ubiquity-would-fail.aspx](http://jeffhandley.com/archive/2008/12/09/why-public-virtual-ubiquity-would-fail.aspx) -Jeff http://ayende.com/3744/consenting-adults#comment6http://ayende.com/3744/consenting-adults#comment6Wed, 10 Dec 2008 07:00:44 GMTWhen a new version comes out... aren't existing apps already targeting a specific (major.minor) version of the .NET runtimes? http://ayende.com/3744/consenting-adults#comment5http://ayende.com/3744/consenting-adults#comment5Wed, 10 Dec 2008 05:00:44 GMTHave 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? http://ayende.com/3744/consenting-adults#comment4http://ayende.com/3744/consenting-adults#comment4Wed, 10 Dec 2008 04:19:43 GMTI 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. http://ayende.com/3744/consenting-adults#comment3http://ayende.com/3744/consenting-adults#comment3Wed, 10 Dec 2008 03:20:50 GMTI 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? http://ayende.com/3744/consenting-adults#comment2http://ayende.com/3744/consenting-adults#comment2Wed, 10 Dec 2008 01:27:49 GMTI think you mean "coddle" rather than "cuddle". http://ayende.com/3744/consenting-adults#comment1http://ayende.com/3744/consenting-adults#comment1Wed, 10 Dec 2008 01:09:28 GMT