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

  • NOTE: This chapter focuses on internal systems and software (not external-facing systems or software stacks / platforms)
  • Old systems generally require more work to maintain as diverge from the surrounding ecosystem
  • The number of still running obsolete systems suggests that removing them is not easy
  • The process of an orderly migration away from and an eventual removal of the obsolete systems is known as deprecation
  • Plan for deprecation during the design phase as to save effort later
  • Deprecation applies to anything from function / method calls to entire software stacks
  • Code is not an asset it is a liability. It has costs to run and maintain. The value of code is in the functionality it provides, not the code itself
  • Just because something is old does not necessarily mean it's obsolete
  • Before considerating deprecation you must research to see if there's a replacement that works for you. There may not be
  • Don't maintain two systems that do the same thing; bite the bullet and fully deprecate the old one
  • Running two systems at the same time also reduces the development velocity of the new system because it has to maintain compatability with the old one
  • One software development metric to consider is "functionality per unit of code" where it pays to remove old code and to write new code efficently
  • Choose deprecation projects carefully, follow through, and completely finish them
  • Moderate the amount of depcreation work that's going on at one time so that it minimizes blocking and creating additional work for other teams (anology used was don't pave all roads at the same time, only some so that traffic can continue to flow
  • Deprecation is hard because things WILL break and you'll have to deal with it
  • When evaluating a new system you should have ready a list of functionality that the old system provides
  • There are emotional attachments to systems and code that can delay deprecation
  • It's hard to convince stakeholders to allocate funds (time) to deprecation because it's hard to see the value
  • Incremental deprecations via in-place refactoring can keep existing system running for a long time without requiring a platform migration
  • Google has observed that migrating to entirely new systems is extremely expensive and costs are frequently underestimated, thus the previous point
  • Designing for deprecation is important, ex: a nuclear power plant is designed with decommissioning in mind



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