Software Engineering at Google Chapter #22 - Large Scale Changes (1 of 3)

  • Many ideas in this chapter trace back to the fact that it's easier to have a single team make all changes across a code base instead of updating their small part of the system and then calling on all users of that system to update their code
  • As the number of engineers grows the size of the largest possible change across a code base decreases
  • In other words, many smaller changes vs a single large change
  • LSC (large scale changes) are defined as a set of changes that are logically related but cannot be practically submitted and applied in a single commit
  • The ability to make LSCs depends on your repo topology. In your organization it may not even be possible to do LSCs
  • At Google they tend to use LSCs for...
    • Replacing deprecated library features
    • Changing common anti-patterns
    • Moving users from an older system to a new one
    • Enabling low-level infrastructure changes (compiler upgrades)
  • The advantage of creating a workflow for LSCs is that is not only scales up but scales down as well (the same workflow can make millions of changes or dozens)
  • The team that has the knowledge to make the change is the one who makes the LSC. A team that updates their library cannot make all dependent teams upgrade their code immediately.
  • LSC can be used to change naming convention discrepancies and solidifying naming conventions
  • Sometimes LSCs are impossible because the infrastructure cannot handle the changes of thousands of files at once
  • Another reason why LSCs may be impossible is due to unavoidable merge conflicts that happen when thousands of engineers are working on the same codebase
  • Haunted Graveyards (systems that nobody knows about or wants to touch) are not conductive to LSCs
  • Small, independent changes are easier to validate
  • Engineer time spent tracking down test failures is more valuable than the compute time used to run the tests
  • At Google it's common for 10-20% of all changes to be LSCs
  • Breaking a LSC into separate shards or chunks makes it easier for code review and testing
  • When making LSCs also consider that you may need to make the change to automatically generated code and not just the code that lives in the repo



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