In a recent ACM Tech Talk, Titus Winters, a senior software engineer at Google, talks about Google’s strategy to managing its codebase.
What’s Google’s secret to software engineering? Titus breaks it down to three principles: time, scale, and tradeoffs.
When a project reaches a certain age, 5 years according to Titus, focus of development crosses over from programming to maintenance. Unfortunately, most developers have never worked on a project that is more than 5 years old, and they do not have the experience, nor the procedures in place, to maintain the project in the long run.
Programming is the “easy” part; if the project is short lived, you do not need to worry about outside dependencies, just get the programming done and any dependencies are unlikely to have changed in the meantime. If the project has been around for a few years, it is possible that other programs your project uses might have updates, bug fixes, etc., which you need to ensure compatibility with, requiring an update to your project. This is where things can get interesting.
Updates are hard; you need to consider all the hidden dependencies, which includes behaviors of your project that users are relying on, even if said behavior happens to be a bug. This can be daunting if you do not have a sound software engineering methodology. To make matters worse, if your methodology is lacking, after one major update, you might have a negative outlook towards future updates and try to avoid doing updates in the future; this is not good for the project, especially if it is being used by a sufficient number of users. You need to have sustainability in mind, and reliably keep your project current and moving forward; don’t be afraid of change.
Scale is usually thought about in terms of resources, such as hardware resources. Hardware resources are easy to scale, simply throw money at the problem and buy a new server. Projects also need to be scalable in terms of human input. This is not something that you can throw money at to solve; sure, you can hire more developers, but what happens when they all work on the same codebase? At some point, all these developers will need to communicate with each other to resolve issues, such as merge conflicts; this might not be a problem with a limited number of developers, but what about hundreds of them?
You need to rely on expertise; instead of a bunch of developers working on everything, give ownership of a particular portion of your project to a single developer or small group, allowing them to become an expert on it. Automation is another key idea, but automation is usually only considered by someone with expertise, otherwise, how would you know what to automate?
Make good decisions, based off data or evidence, not because someone else is doing it. Also consider that data/evidence will change over time; what was once good, might not be good anymore.
I found this insight from Titus quite interesting. I can personally relate to the principle of time; having worked on some projects for close to a decade, what Titus was saying about the difficulties of age really hit home. Sometimes you find the most random things break during updates, and a lot of what I do now for those projects is just fixing issues that pop up from a system update. Even having done it a few times at this point in my career, I dread upgrading a server’s operating system between LTS versions; every time something breaks. I suppose I have learned from my past experiences and adjusted my procedures accordingly, but even with testing “everything” on a non-production environment and fixing what breaks before pushing out an upgrade to the production environment, end users always manage to find something I missed.
During the webcast, I thought that it was odd how Titus pronounced “depreciated”, after reading “deprecated” on the slides (notice the lack of “i”). It turns out that I completely missed the lack of “i”; just like reading misspelled words without a second thought, my brain filled in what it thought was missing from “depreciated”.
So, which one should be used in the context of software? According to dictionary.com:
The winner is clearly “deprecated”. If a newer version of a feature is available, we might keep documentation for the old version around for legacy reasons, but we are expressing our disapproval of the old version by listing it as deprecated.