Software Engineering at Google Chapter #1 - What is Software Engineering? (1 of 3)

  • “Nothing is built on stone; all is built on sand, but we must built as if the sand were stone” - Jorge Luis Borges
  • Software engineering is the “multiperson development of multiversion programs”
  • The distinction between programming and software engineering are ones of scale, longevity, and how many others are involved. Programming is a solitary activity for small programs with a short lifecycle. Software engineering is a team effort for large programs with a long lifecycle. Compare a 10 line Python glue script (programming) to Apache (software development).
  • In software engineering, scaling issues are generally a matter of organizational policy or culture. An organization that values automation and testing will scale better than one with manual processes.
  • Beware of hidden assumptions baked into your thinking when upgrading something for the first time. When it’s time to upgrade those ancient libraries there are lots of things that you don’t think about because they “just work”. The example the book uses is how hash tables are random but some languages keep them in a consistent order so programmers used that "feature" and it was later changed to randomize the order, thus breaking Google’s code.
  • If something is far behind and needs to be upgraded, do several incremental upgrades instead of a “big bang” up to the most recent version. Lessons learned in the first upgrade will be applied to subsequent upgrades and that will in turn make all future upgrades less painful.
  • Hyrum’s Law: “With a sufficient number of users of an API, it does not matter what you promise in the contract: All observable behaviors of your system will be depended upon by somebody”.
  • The above law means that given enough time and enough users, no matter what you change it will break something for someone.
  • Discussions of software maintenance, troubleshooting, and change over time should always consider Hyrum’s Law.
  • Think about the future maintainability of your code. “Works now” (clever code) vs “works indefinitely” (well engineered code)
  • Don’t change for the sake of change, but be capable of change
  • No mistakes were made, but a software’s original design may have made sense and been the best choice available at the time. With time better options become available (optimizations) so one must weigh the risk of the upgrade or migration.



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