Managing Backward Compatibility and Development Time
Time is always tight and estimations are hard to make.
This is written from the perspective of a service owner of a backend service.
Some of us are familiar with the Project Management Triangle. There is a famous quote, "Time, quality, features. Choose two." Managing a project is hard in the real world. We can't have the best circumstances to deliver. In the pursuit of our delivery targets, we have to inevitably prioritize some factors more than others. Sometimes, time is a non-negotiable factor. We can reduce the features or the scope or even consider making new APIs backwards incompatible. We can save time writing more code.
I mean as long as the new features are shipped on time, we are all okay right? - this is a tempting thought when pressed on time. I realised we should unpack this further before making the decision.
Let's assume a scenario where we need a new set of APIs are needed, data are stored in new database schemas and we don't have time.
Who are the consumers of our APIs?
Internal Users
Our Consumers are internal teams that we work closely with within our organisation. As long as we can coordinate our releases, it might be possible to skip backward compatibility for time.
External Users
Backward compatibility is almost always a must. It can be hard to coordinate if another company is involved.
What platforms are our consumers using?
Web
What is the deployment method?
Web is easy when we use in-place deployment (all at once). Once we deploy the new web app with updated endpoints, we are good to go. Our users will use the new website with the new endpoints. Without backward compatibility, the impact is minimal.
For other deployment methods that aim to reduce downtime, there is a possibility that we have both old and new apps running simultaneously. It might be problematic when we have APIs that are not backwards compatible.
Mobile
Backward compatibility is needed. Web apps are deployed; mobile apps are published. It takes time to get your mobile apps approved and propagated to all your users around the globe. There is little certainty that all your users will get to use your new mobile apps simultaneously. Users may even refuse to update their apps.
Summary
TLDR: Although backward compatibility may seem trivial and transparent to the users, that extra effort you put into making your APIs backward/forward-compatible might save you from a lot of stress and headaches when it is time to ship your code.