SECRET OF CSS

“Software Engineering at Google”: Here’s Three Crucial Insights I Learned From This Book | by Mostafa Ibrahim | Sep, 2022


Tips to engineer software in the real world

0*urzQ8nGw0LKFCQv2
Photo by Desola Lanre-Ologun on Unsplash

Moving from university projects or small software apps to large-scale software engineering apps can sometimes be daunting. There are things that you only learn through painful trials and errors in production. Luckily, there are some good books about production software engineering. I have been recently reading “Software Engineering at Google,” and I wanted to share some helpful insights from that book. Here we go.

One of the very crucial things that are usually underlooked or under-appreciated by software engineers is the high level of complexity that the software system will reach in the future.

Surely, this is no problem if you are building a project that will only be used for a few months or maybe even a year. However, if you are building something intended to be used for 10, 20, or maybe even 30 years, this becomes an issue. Especially if you want your software to be used by millions or even billions of people, there are some very important concepts that you have to keep in mind when designing, architecting, and building the system.

These concepts can be hard to stay on top of, especially from the perspective of justifying them to business stakeholders, as they are somewhat intangible and do not produce immediate business value.

Their business value is somewhat delayed and will only be realized in the future. A high-quality project manager will be able to realize the value of spending extra time and resources to stay aligned with these concepts.

One of the very first concepts is the system’s maintainability. Hyrum’s law highlights the difference between software that works and software that is maintainable:

“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 on by somebody.”

And the next on the list is also important.

Having a system that operates the same way at low and high scales is not a trivial task! A specific new role is becoming more widely looked for, and it’s called Site Reliability Engineer.

You would be surprised at the number of engineers in big tech companies whose jobs are solely aimed at changing the infrastructure and backend of the system just to accommodate for higher future loads simply. Those engineers technically don’t build new API endpoints or fancy features that external customers will use.

However, what they are building enables other teams to build those features easily. Building highly efficient distributed systems is a relatively new field that is unnecessary unless you are in big tech. Hence, the resources for such a thing online are not as much as simply building a basic application or some standard features.

For example, in a lot of situations, tech leads simply don’t know how to decide when to break a monolith into a distributed system. It is not like you are going to google a question like that and get immediate steps to follow that will solve this problem.

You will, however, find some guidelines that point you in some direction. But then you start asking even more undefined questions, such as how would you compartmentalize the monolith components?

Which teams would handle which parts? Is the time spent on such a task worth it down the line? Is it going to change the processes as to how teams work?

Answering these questions can take time to research, consult with experienced professionals, and get a consensus across multiple teams or even departments. It is one of the things that you will never have to deal with when doing small-scale side projects.

I hope you enjoyed this quick discussion about some of the challenges that come with software engineering in production. I will be posting more and more of these ideas down the line. Some of these ideas are inspired by this book (which you can check out here), but most of the breakdown comes from my experience working in tech companies.



News Credit

%d bloggers like this: