Definition: Backward Compatibility

back·ward com·pat·i·bil·i·ty

/bakwərd kəmˌpadəˈbilədē/ — noun

The ability for hardware or software to interface with each other, regardless of its current version. If an update to one system interferes with another system’s ability to function, we would say that the former system is not “backwards compatible.”

We have all come across this at some point: after using the same program for years, one day we are told that we need to update our computer, and after doing so, that program no longer works. It is a source of endless frustration and grief.

Software developers are aware of this common pain-point. For many companies, it is a specific goal or even a core value that their systems remain backwards compatible. But, not all companies have the desire (or the resources) to do so.

Economically, backwards compatibility is expensive. In fact, money can be made by designing systems that are not backwards compatible. Remember how awesome Zelda: Ocarina of Time is? Or Mario Kart? Well, you can’t shove your Nintendo 64 games into a Nintendo Wii, can you? Nope. And that’s how the game makers like it. As the technology improves, some things get left behind.

WordPress strives to always remain backwards compatible. (And can cause huge upset when it fails to do so.) This means that (ideally) the plugins you installed last year should continue to work with the new WordPress core software update. The amount of testing and experimentation that has to go into these updates is unfathomable. There are 46,886 plugins available to add to your WordPress site, as of this publication. These are plugins submitted by individuals or organizations with varying degrees of upkeep.

A three way balancing act: the needs of the user, the needs of the developer, and the needs of the business

Backwards compatibility tradeoffs are that the software can’t be developed as quickly. New innovations in software (new features of language, or just new features being developed for an application) tempt developers to use them, to either improve on old ways of doing things, or add entirely new capabilities.

Supporting old platforms comes at a price: at worst, it rules out using tempting new technologies, and at best, it requires a lot of time, consideration, and care in the development of the new technologies.

Therefore, software that is devoted to backwards compatibility will tend to advance more slowly, but with a lot less frustration for its users. Software that isn’t devoted to backwards compatibility will tend to be shinier and newer, but with a lot more frustrations for its users when things break all of the time.

Again due to this tradeoff, a devotion to backwards compatibility is essentially a decision to prioritize the needs of users — stability, consistency, reliability — over the needs of developers — novelty, creativity, tinkering, pushing the envelope to make things better, often at a cost to the business. Backwards compatibility testing is expensive. Developers appear to lose out in this equation, but not when you take the long view: Developers serve users, so user happiness with a piece of software means developers’ work is valued by others. If users lose out due to developers chasing the shiny new thing, eventually the users will abandon those developers’ projects in favor of more stable platforms, and then what has the developer gained?