[sophacles]

At some point, we need to kill the myth of backwards compatible. This has caused more problems than it fixes. Further, at this point in history, app updates are trivial and built into everything, so retaining backwards compatibility is not so much of a necessity.

When designing APIs, use versions and have a kill date in place. Even if you don't change the API, release the same one under a new version number. Kill access to the old version on the kill date. Keep N versions accessible at a time, to reduce the burden on app writers, but don't slack on the kill date. This will give you a timeline and procedure to avoid hacking in crazy backwards compatibility, and targets for total rewrites.

Yes, people will still complain. It's OK though if you provide a reasonable balance.

[mattmanser]

Myth? MS built a very successful business on it.

You know what happens when you get kill dates? One day all of a sudden half the web will stop working. There's a reason why people start back flipping to support out of date calls.

Customers don't care why your software just broke or whose fault it was, all they care about is it broke.

[georgemcbay]

I'm actually quite fond of the way Microsoft historically bent over backwards for backward compatibility, but OTOH Facebook is also very successful and has a very successful ecosystem of third-party users of their APIs. Facebook is like the anti-Microsoft in that they randomly change and break their APIs at such an alarming rate that you have to wonder if they are intentionally fucking with you if you code against their APIs.

Obviously the needs for a web API and the needs for an API with a specific binary ABI on a local OS are quite different but I think for either environment, most API developers can comfortably fit somewhere between those two extremes where they don't continue to support inherently unsupported API usage, but they don't break something randomly every week.

[grogs]

Facebook making breaking changes does piss people off. It's interesting that it doesn't kill the apps. I can't remember any single change Facebook have made - possibly just because tere's so many - but I do remember when twitter made everyone switch to OAuth. People complained about that kill date.

[planckscnst]

I think developers tend to love backward-compatability while users hate it.

As a developer, it means we don't have to keep digging out the old projects and porting them to the new API.

As a user, it means we are left with systems that have many years of cruft and with features being held back from systems because they couldn't make it backward-compatabile.

I think most users are willing to pay any higher price that will result from developers being required to work harder to port their software.

[barrkel]

Users love it when their software still works even after they've upgraded another bit of the overall system.

[anonymoushn]

As a developer, I would rather have my code break than continue to use a terrible API.

[dvhh]

How about fixing your application, because your terrible API were deprecated, for an application that is quite old, bit still in support ? (and of course for free, because client don't expect to pay for a compatibility fix).

[sophacles]

If you have your kill-date iterate rapidly enough, and advertise it well enough, people who build products on your API will keep up, or the competitors will and take their business.

Heck, if you want to be really hand-holdy about it, have an warnmesage attribute in your returns that mentions various issues, and start throwing deprication warnings some $time before the kill date as a reminder.

And the number of bugs and security holes coming directly out of backwards compatibility in MS products was a very big issue for a very long time. Lately they have been doing much less in terms of backwards compatibility (e.g. run in "compatibility mode"), probably as and outgrowth of this.

[6ren]

Or customers will switch to a competitor's API that doesn't keep trashing their app with "improvements' that are not usable for that specific app.

But your proposal is interesting: if things are improving all the time, API-users need to be upgrading all the time and adapting to the new features anyway - so any incompatibility necessary for those features is no problem.

It depends on the phase of market (new, growth, mature, stagnating) for that specific API. At the moment, most web-APIs usages are "new".

[cek]

I think sophacles is onto something here.

In my post I tried to make it clear that backwards compatibility is a challenge for successful APIs.

However, I guess if you don't want to make your APIs successful you can do all kinds of things that make them harder to use, like putting in draconian kill-dates, warnmessages, etc... Make sure your documentation is extra-long and wordy too while you're at it.

Because, sophacles, is right: if you don't have a successful API you don't have to worry about pissing customers off.

[sophacles]

This is a false dilemma. Just because you set up some opposing conditions: backwards compatibility or unsuccessful api doesn't actually make it true. Just an assertion.

Having a reasonable end of life on support never hurt apple. There are lots of things that I can no longer run on the latest version of OSX. This happens every time the OS upgrades. Except of course they don't use versioned APIs, so it is much less planned for and not really as easy to deal with for devs.

I'm not saying make a shitty API, I'm saying, if you have the people who depend on your product know that changes happen, they can prepare for it. If you release a new version of the API every 6 months, and only support them for 18 months, you can make the api migrate slowly enough that it isn't a serious change for each version.

In native code: anything compiled to old APIs can link to old versions of your library, and just work the same way. In web apis: the world changes faster than the 18 month thing anyway, so whatever.

If people want to depend on your bugs, you told them not to, they can deal with the changes.

[chii]

"There are lots of things that I can no longer run on the latest version of OSX. This happens every time the OS upgrades."

This is what i hate about osx - they freaking change the OS drastically, and my apps break. Sure, there might be a new version, but when i compare mac OSX to windows, windows kicks ass because you know what? i can _still_ run crap that i used to run in win95!

[loverobots]

Having a reasonable end of life on support never hurt apple.

Just because the iPhone is doing great, doesn't mean businesses and other slow movers avoid Apple because of this. My point is, we don't know if this hurts Apple or not.

[groby_b]

Yeah, Apple has no success whatsoever with their aggressive deprecation strategy :)

[dlitz]

> Myth? MS built a very successful business on it.

It's also an unsustainable business. How long do you think MS will be able to maintain backward full compatibility? 100 years? 200 years?

> Customers don't care why your software just broke or whose fault it was, all they care about is it broke.

Customers aren't engineers; they don't know better. We do. In any, it's going to be cheaper to abandon the stubborn customers than it will be to maintain decades worth of backward compatibility, at some point.

[ajross]

100 years sounds reasonable. Old APIs simply get frozen and new ones take their place. Apps written to .NET, for example, aren't bound by compatibility concerns with the early win32 GDI implementations. Cocoa apps aren't impacted by Carbon's compatibility concerns.

What's the option? Throw whole platforms out and start over every 15 years? Does that scale? It has so far only because the industry has been growing (more smartphones than PCs, more PCs than workstations, more workstations than minicomputers, etc...). But it won't grow forever.

[blantonl]

*myth of backwards compatible"

What is the "myth" of backward compatible?

I wholeheartedly agree with your second paragraph regarding versions and kill dates - but every API is different. In our case, when our API changes/versions/deprecates - WE are directly held responsible by customers of consumers of the API - since API consumers trumpet the fact that they have integrated with our API.

On the surface, versioning and kill dates are great end-all solutions, but the reality is API consumers have a ton of leverage when your API is successful at generating revenue for you. Especially when those consumers are sending lots of revenue your way from their own customers, which think you are the source.