Isn't it amazing and yet completely useless how you can still run MS-DOS-era software on Vista/Win2008? I don't think people fully realize the innovation that has been sacrificed on the alter of compatibility.

And, of course, I spelled "altar" wrong in the above post. Perhaps if the English language weren't so backwards compatible the grammar checker would have found it!

What's amazing is how crappy the dos prompt is in the year 2008. Even with powershell, the integration with the native environment (copy and paste, window resizing, performance) is awful.

It's practically unusable, but compatibility is great!!

@Jonathan

Think of IE8, and how much cleaner its W3C compliance would be if only they could discard all of their special parsing functionality of previous versions.

It gets even worse when it comes to windows networking protocols. I've read that the windows network communication between machines (file shares/AD printer sharing etc) could be multiples faster if it wasnt for maintaining windows 98 compatibility.

One can only how much money is spent (and opportunity lost) for downgrade compatibility, but this is one of the historical advantages microsoft claims over the *nix platform: everything microsoft branded is expected to be compatible over a wide range of versions.

since you are purchasing the software (not free) it is assumed the support that comes with your purchase is as top notch as possible. A nightmare scenario for MS is users feeling like they are forced into paying money for upgrades "just because".

@pete

"A nightmare scenario for MS is users feeling like they are forced into paying money for upgrades "just because"."

coughVista!cough

:)

Doesn't Microsoft break backwards compatibility all the time?

They just give it a new technology name.

Ayende, yep, you have all the reasons to go into rage, because they promised compatibility, and then broke it. And I hear you on the "it's not just 1 or 0" point. But the thing is that the population of MS users generally cares about backwards compatibility a lot. Simply because they don't like to worry about their code breaking when they upgrade (and lots of these people have metric craploads of code to worry about). A lot of people who make these purchasing decisions value predictability far more then the benefits that could be had from redesigning the existing APIs. Or, in other words, when you have an existing codebase, it pretty much always will cost WAY more to deal with breaking changes, then could be saved by using the new and improved APIs. So while theoretically there are shades of gray in this picture, but for the practical purposes it is pretty much black and white.

(And PHP is not a comparable example. Because, as far as I know, that platform is either used for puny little projects where there is no codebase to speak of, or it is Facebook, and they have their own version anyway)

How do you address the issue of 3rd-party components whose purveyors may have gone out of business?

Java is a little different - especially with their generics support as they not only supported backwards compatibility, but also forwards (ie an older version of the JVM can run newer versions of packages).

This is something that not even we try (ie you can't run 2.0 on 1.x and you can't run 4.0 on 2.0).

What about maintain compatibility between CLR versions, and then MS can break stuff if needed when the CLR gets upgraded.

Doesn't a .NET program run only on the CLR version it was built on?

Compiled against .Net 1.0 or 1.1 -> run on CLR 1.1

Compiled against .Net 2.0, 3.0, 3.0, 3.5, 3.5SP1 -> run on CLR 2.0 SP1

Compiled against .Net 4.0 -> run on CLR 4.0 (I think)

Well said, Ayende. I agree wholeheartedly. If you choose to upgrade the platform, then you should expect some pain and possibly changes. If you can't live with that then don't upgrade the platform!

@David - perfect reason to never use 3rd-party components. Open source is your protection against this sort of lock-in.

@GT -- a decent grid control costs $500. About as much as a day's worth of developer's work. Can you build a decent grid control in 8 hours? No? Right, I did not think so. And "open source" is not a solution -- first of all, not everything is available as open source, and second of all, it breaks too...

Hi, I'm formerly from PHP world. And I can say that lack of compatibility was a real issue even before arrival of PHP 5. I remember as the first thing we used to ask when something did not work - "are you running exactly the same version"? I guess (IMHO) such things give a platform a sence of not being reliable enough for serious business...

"Backward compatibility is not a binary value."

Yes it is, once your income depends on the fact that customers are happy and want to STAY on your platform.

Like I said in a reply to the previous post: you think as an OSS developer, which is cool, but do consider that an OSS framework has different rules: if it breaks something and someone cares, get the source and fix it yourself, or deal with it.

If the customer paid money for the framework and/or it's closed source, the customer doesn't have that option, and therefore is dependent on the fact that the stuff is backwards compatible. And there's no such thing as 'being a little bit backwards compatible'.

What you seem to forget is that it's not wrong to break stuff with newer versions. You just:

• have to document every break

• provide reasoning why the break was necessary

• if possible provide an upgrade path/alternative

I'll give you one anecdotal example. When we released v2.0 of llblgen pro as beta, one beta tester immediately ran into a problem right after we released it: in v2.0 we supported .NET 2.0 and nullable types. We simply generated all entity fields which were nullable and of a .NET value type as Nullable(of T). But that breaks existing applications so upgrading would be a pain. We never thought of that, but as his project was pretty big, we had little choice but to add a setting to make it optional, so the user could tweak what's generated so people could upgrade with ease and had control over the problems caused by breaking code.

It's not always due to api changes that things break. Behavior changes are just as nasty, and perhaps even worse. Still, it's key that people who want to upgrade (!) are able to do so with little to no problems at all. That's why backwards compatibility is required to keep those people on board.

Take it from me: if your commercial toolkit, the profile for nhibernate, works with nhibernate 1.x and 2.x and in v1.1 you drop nhibernate 1.x by saying people should upgrade to v2.0, you'll likely lose customers over that (after you've to deal with their rants first ;)). And rightfully so. So I bet you'll then likely revert that choice back, for the simple fact that the toolkit isn't for YOU, it's for your customers. THEY suffer if you drop backwards compatibility.

Isn't that the different between major and minor version is for?

Major = new feature, may not be backward compatible

minor = bug fix

Don't want software to break then don't upgrade.

So, "backward compatibility is not a binary value," but "if I have to pay the price for backward compatibility, then I want 100% compatibility?" Yes, I do in fact find that to be quite inconsistent. The real reason to be annoyed at the breaking changes in SP1 is because they were taken in a service pack, not a major version. Service packs should always be 100% compatible, regardless of your stance on breaking changes.

I am often frustrated by the complete unwillingness to take breaking changes that would clearly result in huge gains going forward. But I agree with Frans, that you are only looking at the issue from your own point of view, without taking into account the point of view of Fortune 500 companies and national governments. And I promise you, Microsoft considers the opinion of the latter to be more important than yours or mine, as well they should (no matter how much it might piss us off).

David,

You are trying to merge two unrelated points.

For me, backward compatibility is not a binary value, but Microsoft certainly seems to think and act so. As such, if I have to go through the pain because of that, I would demand the benefit.

That is my "at least I got that out of this" attitude, trying to make the best of this.

There is no inconsistency here, because the base parameters for each statement is different

That's interesting, because I think it is you who is trying to merge two unrelated points :) You are implying that a design philosophy that includes an extreme reluctance to break existing application also equates to never releasing a single bug, ever. Even a 100% commitment to backward compatibility does not preclude the possibility of a bug slipping through. Unless you are under the impression that the breaking change was intentionally introduced.

And I don't agree with your assertion that Microsoft sees backward compatibility as a binary value. Rather, I think they choose to operate at around 0.99999, whereas you would prefer them to operate at around 0.99.