Watch out! Behind you! - Backward Compatibility

We’re often taught to forget about the past and focus on the future, but when it comes to backward compatibility the exact opposite is in order. Backward compatibility ensures that neither the user, system or data, encounter any negative effects to existing functionality when new features are introduced. It can be tricky to accomplish when you’re only looking forward, so it's important to consider the holistic lifecycle of your application to be successful.

Some types of applications require a more detailed eye and conscious effort to ensure it's backward compatible. A few of such applications are:

• Applications that maintain the user's state

• Applications with live deployments (i.e. the application has no downtime and users have continuous access to it)

• Applications with updates that are not initiated by the user

If you're anything like me, the adrenaline rush of releasing a new feature or product for a client is quickly brought to a halt when testing the compatibility with existing features. To lessen the blow of this effort, backward compatibility cannot be treated solely as a test cycle. It must be built into the design and development of a new feature.

Here are some small tips to help make backward compatibility part of the holistic application lifecycle and not just a test.

Design

When designing new features keep in mind the impact to existing users. Questions to ask yourself are:

• Will my existing users be able to exercise the new feature, if not, can I provide a means via back-end data load or manual effort to provide the benefits of the feature?

  • If possible update the back-end data for existing users prior to deploying a new feature if this update will allow those users to take advantage of it once deployed. Your users will thank you for not burdening them with the tasks to use it.

• Will downstream applications receive additional data with this new feature and how can I ensure existing user data also is updated if necessary?

  • Be sure to manage the external application dependencies for both future and existing users. Interfaces between external apps should continue to function with or without the new data if that data will not be available for all users.

• How can I provide seamless transition to users who start a task in my product using an existing feature but finish using the new feature?

  • Like external application dependencies, internal application flows should be able to function with or without data, if that data will not be available for everyone. Branches in logic can be created to send new users down a different path from existing users. Flagging users with a version when they access the application help divert them down paths that won't break their experience until the required data can be obtained to move them to the newer release. Of course these flows can be phased out once all users are able to utilize the newer version.

Development

We often think development consists of taking a design as-is and implementing it; but experienced product teams know this is far from the truth. There are always key things the designer may not be aware of that impact backward compatibility for development. Some key questions lead developers would want to ask are:

• Data Structures: Am I introducing any new data structures that won’t exist for legacy users?

  • If so be sure to verify that the object exists before using it, and if necessary build it or stub it out.

• Classes and Method: Do I have any classes or methods that should not be invoked by legacy users?

  • If so be sure to check upon entry is the flow is appropriate based on the user's data.

• Legacy Phase Out: Can I phase out legacy code that is run on a cycle for users?

  • Code that is run on a cycle for all user's can easily be phased out because next time it runs it can be moved to the new code base.

In summary backward compatibility can be a daunting task if not taken into consideration early on. Considering these simple questions can make your life easier and can minimize production defects and poor user experiences.