Software Engineering at Google Chapter #15 - Deprecation (2 of 3)

  • When designing ask yourself:
    • How can I replace parts of my system incrementally?
    • How easy will it be for my customers to migrate to a potential replacement
  • Don't start projects if your organization isn't committed to the entire lifespan of the product
  • Once a software system exists the only options are to deprecate it with care, support it, or leave it to die; all are valid options
  • There are a range of deprecation options from a slow and steady migration to a "turn it off today" deprecation
  • There are three main types of deprecations - advisory, compulsive, and warning
  • Advisory Deprecation:
    • No deadline, no enforcement
    • Tells users to use the new system / function
    • Do NOT put out an advisory deprecation when the new system or function is still in beta
    • A strong tactic when the new system offers significant advantages, it's easy to get people to switch
    • Consider providing self-service tools for the migration
    • Users hesitate to migrate when there are only minor benefits so trumpt the major ones
    • A deprecation advisory is not something to post and walk away from
  • Compulsory Deprecation:
    • Has a hard deadline
    • Create a dedicated team of experts to help users migrate away from the old system
    • The deprecation schedule can change but you must also empower the team to turn off the system when it's time; users may break but they were warned
    • If you deprecate a system without allocating staff to deal with the consequences of the deprecation, it will feel mean spirited to other teams because they are forced to do the clean up work
    • Google's monorepo + dependency graphs give huge insights into what interacts with what
    • Turn off the old system temporarly for increasing amounts of time in order to see what fails (eg: turn it off for 1 minute and see what fails / alerts, clean up, document, then repeat for 3 minutes, 5 minutes, 20, 1 day, etc)
    • The deprecation team should announce these planned outages ahead of time so others can watch for effects during the outages (error increases, etc)



Thank you for your time and attention.
Apply what you've learned here.
Enjoy it all.