Sustainable Software
08 Feb 2022How to Sustain Software
The Three Main Ideas
I recently attended an ACM Tech Talk about “Software Engineering at Google” where a couple of senior software engineers talked about what they do in order to maintain “arguably the largest codebase ever”. In this talk, the engineers enforced three main concepts, which were time, scale, and tradeoffs. I was first made aware of these points through the abstract that was provided before the talk, but I was curious as to how these three ideas correlated with each other and why they were so important to the process of Software Engineering. This is the mindset I entered with leading up to the tech talk, and after the tech talk was over, the first thing that I thought of was “I now have a slight understanding of why Google has been able to maintain and keep up with the trends throughout its lifespan so far.”
The First Concept: Time
To kick off the talk, the first concept was time. Time is something that is very relative and depending on how much time you invest into a piece of code, it can be categorized into many different things. We look at time through units such as hours, days, weeks, months, years, and decades, and with each unit, we move further and further along towards to the goal of achieving the idea of Software Engineering. When we first start off, programs that we work with for hours or days even are just programs, and slowly, as we invest more time and effort into them, they gradually move into the category of Software Engineering as they escape the field of Programming. The main point about time, as far as I understood, was that sustainability is the goal of Software Engineering and that we should be able to update and upgrade our code safely as needed over time in order to be able to achieve that goal of sustainability. As the engineers mentioned in their presentation, “Software Engineering is not merely programming - it is the art of making a program resilient to change over time.”
The Second Concept: Scale
Moving on to the second main concept of the talk, we have scale. When I see the word scale, the first thing that comes to mind is balance. How do we balance growth of our codebase with the bugs and failures that we may encounter along the way? In the talk, multiple methods were brought up as to how to deal with code deprecation as our systems grow and changes need to be made. To summarize, the traditional methods included marking the old version deprecated and introducing a new one, doing the same thing as the previous option plus enforcing others to update to the new one by a certain date, and finding someone to build a change to modify the API. The better approach that was suggested was letting the team responsible do most of the work. This makes sense as they would know the code the best and they would have the best idea on how to fix it. The next part of scale tell us that things that must be done repeatedly need to be done in a sublinear fashion. This essentially means that we need not expend our full efforts and resources into doing something that must be done repeatedly, and the example that they brought up was weekly merge meetings. By avoiding these weekly meetings, we lift the restrictions of risky merges and allow the developers to choose where to commit and what versions to depend on. This allows us to not be tied down to these merge meetings, and as a result, we end up completing these tasks in a sublinear fashion.
The Final Concept: Tradeoffs
The third main concept of the talk was tradeoffs. This one relates quite a bit to scale in the sense that we have to learn how to effectively balance quantities. We have to know how to analyze the overall situation, and use evidence in order to make decisions that will be better for us in the long run. We need to analyze tradeoffs and make sure we choose the option that results in more sustainability. We also prohibit super-linear scaling in tradeoffs, meaning that we cannot overextend our efforts and resources into doing something. We also need to be sure that we can reevaluate these tradeoffs, or anything in general that we do, in order to make sure we made the right decisions, and if not, we can change course to drive in a new direction that we think will be better for us in the long run.
My Opinions
My Experiences
After learning and understanding these three foundational concepts of Software Engineering, I can safely say that I agree that all three of these points are essential in creating and maintaining a Software Engineering project. I myself have not been involved in Software Engineering projects that are as large or vast as Google is, but I do have some experience in the field of Software Engineering. One notable example I can think of is in regards to my Master’s project, which is deployed on the eduWRENCH site here. For my project, I created a module to teach students about energy-aware distributed workflow execution. Throughout the course of the project, there have been multiple changes made in order to maintain the sustainability of the webpage. One change was as a result of user feedback that we got from students in a graduate-level course, so with that feedback, I made the necessary changes to the webpage in order to maintain the sustainability of the page. Another change was having the WRENCH API code, documentation located here, be updated multiple times over the course of working on the project. As a result, there were some changes that had to be made to my own project in order to reflect the new API changes to keep up to date with the latest version of the WRENCH API. This is one of the biggest projects I have worked on up to this point in my career, and I hope to continue working on bigger and larger-scale projects where I will take what I learned from this talk and apply it when necessary.
My Actions in the Future
Some concepts that I took away from the talk that were the most valuable and that I plan to apply to projects I work on in the future are sustainability is always the goal and learning how to make evidence-based decisions in order to best benefit in the future. In my opinion, the most important point to come out of this talk was that sustainability is always the goal. I feel like sustainability is the idea that links all three of the aforementioned concepts together and it is one of the concepts that Software Engineering is centered around. Being able to modify code to make sure it is sustainable is something that I will admit I am not the best at doing; I just go with the flow and I use whatever works best for me at the time without having any future implications. However, I have not worked on large-scale projects so I have some leeway there, but in the future, when I get the chance to do so, I will make sure to put the idea of sustainability at the forefront. As for making evidence-based decisions, I plan to apply this if there comes a situation where I have multiple options and I have to choose what is best. I will try to make that decision after analyzing the overall situation and also with keeping sustainability in mind. While weighting my options, and looking at all the evidence presented for each side, I will try to put that all together in order to make the best decision that I think will produce the most sustainable result.