What are the things you consider when writing code?

Does it work?

Is it efficient?

Is it readable?

Will it actually be used?

All good things to consider. And I’m sure you think of many more.

Do you also consider backward compatibility?

This is one charactaristic that I find is often overlooked. Often because it’s considered a non-issue, even in places where it actually is a very important issue.

For mobile or desktop apps like, say, Microsoft Word, the desire for backward compatibility is usually pretty obvious. Of course you want the ability to read documents you created last year. Or last decade. You likely also want to create documents that others, who aren’t using the latest version, can read.

What if your software is entirely cloud-hosted? Should you compare about backward compatibility?

Well, if you have a microservices architecture, then backward compatiblity is still important, although perhaps not for as long. A key benefit of microservices is that you can upgrade one service without upgrading all services. This implies that some level of backward compatibility must be maintained.

If service A depends on service B, then you can’t just upgrade service B willy-nilly without considering that service A depends on it in some way. This obviously applies to complete features: you can’t remove the file storage feature from service B that service A uses. But it can also be much more subtle things, like RPC formats. If service B suddenly starts expecting a new query parameter on every request that A doesn’t know about, you’ll have some serious problems.

But what if you’re running a monolith? Surely you’re out of the woods, right?

Not so fast.

If you want to take advantage of rolling, canary, or blue/green deployments, then there will always be times when you’ll have two versions of your application are running at the same time. Are these two versions compatible with each other? A change to session cookie formats, for a real-world example, could prove very frustrating for your users, even if the new version converts cookies from the old to new format… because your visitor may talk to both the old and new versions, even on a single page load (depending on how your load balancer works).

TL;DR; backward compatibility is a valid, and important, concern in most applications, at least some of the time. Learn to watch for these cases!