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)
< BACK NEXT >
Tweet


   


   

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