Book: Software Engineering at Google
Chapter: 15 - Deprecation
Summary:
Deprecation is the process of migrating away from old and obsolete systems, with the goal of completely removing them. It is a process that requires careful planning and execution.
Deprecation happens because the environment around the system changes and improves over time. The cost of maintaining the old system may increase over time.
Deprecation is ideal for systems that are obsolete and a newer replacement system exists that can handle most of the functionality provided by the old system. It is possible that the newer system use resources more efficiently, has better security, is better designed and/or has fixed certain bugs that occur in the older system.
"Code is a liability, not an asset". Code comes with a cost, not only the cost to write the code, but also costs to maintain the code in the long run. Thus, it is crucial to maximise the amount of functionality per unit of code that a particular system or codebase can deliver.
However, deprecation is not easy. Some reasons include:
People may be using a system in unexpected ways, and their workflows may be affected with a migration to a new system, as their workflows are not accounted for when developing and operating the new system.
A replacement system must already be available to deliver the same or more functionalities as the older system. It is rare that all the features in the old system are available in the new one.
Some people may be emotionally attached to old systems
It may be hard to justify deprecation. Replacing old systems comes with a cost, such as depriving resources to develop new features. It may be difficult to convince stakeholders that the investment would be useful.
The deprecation process is not a straightforward task. It must be carefully managed and the users play an important role in the process.
Advisory deprecation: For deprecations where there is no set deadline, and it is not a high priority. This is useful to let people know of the existence of the new system, and users can migrate to the new system on their own accord. This way of deprecation reduces the need for the system operator to perform the migration on behalf of the users, but it lacks enforcement and can take a very long time.
Compulsory deprecation: This type of deprecation comes with a deadline, and users will not be able to access the old system after the deadline. However, this way of deprecation may not be straightforward, as it still requires work on the users to perform the migration. Enforcement is still necessary here, otherwise it can cause a conflict between the system operators and its users.
For both types of deprecations, deprecation warnings are used to warn users that a particular system will be removed in the future. However, a deprecation warning must be actionable (something that the user can work on directly) and relevant (appears at the right time to the user). Too many deprecation warnings can lead to "alert fatigue" and cause the user to ignore them.
For a successful deprecation process, it must have the following elements:
Process owners: People who are in charge of the deprecation process, to make sure that the deprecation is on track.
Milestones: Using various measurable checkpoints during the deprecation process allows the team to evaluate their progress on the deprecation, similar to how milestones are used when developing new products.
Deprecation tooling: Specialised tools that can assist in the deprecation process, such as discovering how and who uses the deprecated system, migration tools to assist in migrating to the new system, and ensuring that the uses of the new system are not being actively removed
Overall, the deprecation process comes with social and technical challenges that must be carefully overcome through policy and tools. While there may be costs involved in the process, it can benefit the organisation in the long run and is essential for long-term sustainability.
Book: Software Engineering at Google Chapter: 15 - Deprecation
Summary: