Chapter #1 - What is Software Engineering? (1 of 3)
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
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
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
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.