A strong commitment to backwards compatibility means keeping your mistakes

June 13, 2021

Plenty of people like backwards compatibility, especially strong backwards compatibility. But it has what is a sometimes unpleasant consequence, which is that a strong commitment to backwards compatibility requires keeping your mistakes. Or at least many of them. To put it one way, you need to keep mistakes that work, and of course you have to keep them giving the same result as they currently do. For example if you provide an API that people can use to express potentially conflicting things and you don't reject the attempt but instead give some deterministic result, you're stuck with it.

You don't have to have a strong commitment to backwards compatibility, of course, and many people think it's better not to. Microsoft Windows is a big example of such a strong commitment (what has sometimes been called 'bug for bug compatibility'), and while it's given Microsoft a lot of commercial success it's also left them with a lot of technical challenges that have required heroic (and expensive) work to deal with. Backwards compatibility in general is definitely something that helps some groups at the potential expense of others, and it has a cost regardless of whatever benefits it gives to people.

But if you're going to make a strong commitment to backwards compatibility, it comes with the warts, including that your mistakes have to be preserved. If you don't want to have to preserve your mistakes, you should be honest about the limits of your commitment. You don't have to do this (you don't have to do anything), but if you don't it can surprise people and make them unhappy.

(These days, one limit you might want to write in is that you'll break backwards compatibility if it's the only way to fix a sufficiently serious security issue.)

Another way to not have to preserve your mistakes is to do your best to make sure you aren't making any before you commit to something. This can mean not shipping something at all until you're confident in it, or only shipping something as explicitly not covered. The latter is dangerous, though, because regardless of what you say some people will come to rely on your 'experimental' feature and then have problems when it changes.

(Among other reasons, people will rely on experimental features when it's the only way to get their work done. If your choice is 'don't do this at all' or 'rely on an experimental feature', a lot of people will be strongly pushed to the latter. These people are not making a mistake; they're doing something you can predict in advance if you want to.)

Comments on this page:

I wholeheartedly agree. How I approach it is writing a program in discrete segments, each carefully considered. An interface can be either complete or with room to grow. Any messy internals need no such guarantees. If I were unable to do this, documenting such be fine.

Unfortunately, this approach requires the scarce resources known as intelligence and foresight, which most programmers lack.

Fortunately, I realistically have few or no users to displease, and programming only for myself allows me to disregard others.

With apologies to Theodore Kaczynski:
Postel's Law and its consequences have been a disaster for software development.

Written on 13 June 2021.
« Rust 1.x seems to not always be backward compatible in practice
Some notes on Firefox's media autoplay settings as of Firefox 89 »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jun 13 23:54:30 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.