Backward Compatibility
By its nature, software is subject to frequent change. In general, software isn’t particularly static and can be rapidly reconfigured to adapt quickly to changing circumstances in the market, security landscape, and whatever industry it serves. This is one of the main reasons that software is eating the world right now – it’s because of its rapid ability to change. However, this adaptability can also be a weakness if you aren’t careful. Most software these days includes integration points of various sorts so that other software can work with it. If the people integrating with your software happen to be paying you, then it’s crucial that you control the way your software interfaces change so that you disrupt your users as little as possible. To make things more complicated, not everyone always interacts with your software in the way you expect. You may find, for instance, that people directly interact with an underlying database, use web automation to push data into your system, or even automate your user interface as a sort of “back door” integration method. If you want to try and ensure backward compatibility to the degree possible, there are a few practices you can use that will make this easier. While we are planning to have more episodes discussing backward compatibility in various contexts, there are some general rules that you should follow regardless of how other software is interacting with your software. In particular, these rules are focused around the idea of limiting disruption to your users while still allowing as much flexibility as possible for your development team. Disrupting your users a little bit will irritate them, while disrupting them a lot makes it more likely that they will flee your platform for that of your competitors. Keeping backward compatibility is a royal pain at best. As your software gets more mature and has more people integrating with it, don’t be surprised when you find that you have to spend significant effort keeping your code from breaking other people’s integrations with your product. Once your software is stable and in use, you no longer have the ability to change things at the edge as quickly as you could when you were starting out. However, if you are careful and plan ahead, you can often significantly reduce the amount of time and effort that are required to be able to make changes to your software that impact other people. Best of all, these best practices can often result in your integration points being more useful to your own team as well. Episode Breakdown Use Semver religiously. If you can’t communicate version changes in a clear and widely understood manner, then everything else we are about to suggest will be impossible. Semantic versioning is a good way to do this. With Semver, versions are expressed in three segments (Major, Minor, Patch). Major version numbers are incremented when you make breaking changes. Minor versions are incremented when you add functionality in a backwards compatible manner. Patch versions are incremented when you add bug fixes in a backwards compatible manner. Semver is a great way to communicate changes to your users in a way that makes it easy for them to see how much trouble an upgrade will be. This doesn’t mean that you don’t need to include release notes, however. Keep on top of YOUR dependencies. Nothing can force you to implement breaking changes on your users faster than having one of your dependencies force you to quickly make sweeping changes in your code. While some vendors really seem to love to make sudden sweeping changes that cause major problems among their users, most vendors at least attempt to handle breaking changes in a sensible manner. If they don’t, you should reconsider your integration with them, because they are hurting your users in a way that causes yo...