Software Engineering at Google
Recently I came across the book “Software Engineering at Google” at my workplace and decided to give it a try.
I read the first chapter and given the content of the book, I thought it would be great to take notes and come back at it again in the future. So I decided to jot down a few notes here.
Software Engineering
Software Engineering!= Programming
Software Engineering is the set of policies, processes, and tools need to make the code useful for as long as it needs to be used and allowing collaboration across a team while Programming is the act of producing code.
Things to consider in Software Engineering
Time and Change
Nothing is constant, everything can change. Especially for software, it is unpredictable. It needs to change overnight or it might run smoothly for years.
We can’t aim for “Nothing Changes” because, in this evolving world, you can’t predict Heartbleed or Meltdown and Spectre. If not for the feature changes, you will need to change something for fixing the security issues.
Also most of the time, the more you delay the upgrades, the higher will be the cost for upgrading.
Remember that, Every change breaks someone's workflow. [3]
Scale & Efficiency
The most precious asset of a software organization is the codebase itself — also needs to scale (Questions like how long does it take to pull a fresh copy of the repository, how long does it take to do a full build — those needs to be monitored actively).
If you liked it, you should have put the CI test on it. (The Beyonce Rule — as they call it).
Shifting Left: Catch the bugs earlier in the development lifecycle. Try to incorporate code analysis and review meetings before the code is checked in to version control system. Higher the cost will be if the bug is found later in SDLC.
Factors that affect the flexibility of the codebase
- Expertise: if you have enough experts(willing to answer any questions), you have an army of expert developers working on the project.
- Stability: Adapt to newer releases frequently so that you won’t run into any breaking changes in future upgrades.
- Conformity: As the code has been upgraded frequently, there is less code that hasn’t been through upgrade already.
- Familiarity: As we start to do this frequently, we can spot the redundancies and attempt to automate.
- Policy: Ensure that we have automated tests in the CI pipeline so that we don’t need to worry about the unknown usage of the code.
Tradeoffs and Cost
By Cost, we don’t just mean dollars but one or more of financial costs, resource costs(e.g. CPU), personnel costs(e.g. engineering effort), transaction costs(e.g. cost to take any action), opportunity costs(e.g. cost to not take an action), and societal costs(e.g. impact on society at large).
Decisions should not be “We are doing this because I said so”. Rather they should be backed by legal requirements, customer requirements, and data (at the given point of time). Also, be aware that not everything is measurable or predictable.
Consistency has great value, but generally comes with its own costs, and you can often win by doing your own thing — if you do it carefully.
Revisiting decisions and making mistakes is okay. You could make a decision based on the current data but as and when the new data becomes available, you can revisit the decisions.
Be evidence-driven, but also realize that things that can’t be measured may still have value.
Let me know if I have missed anything or you feel something is incorrect.
References:
[1]: Software Engineering at Google
[2]: Site Reliability Engineering: How Google runs production systems
