|
|
posted: August 28, 2021
tl;dr: Being aggressive about deleting code, branches, cloud infrastructure, and services can save time and money...
I’m more aggressive than most developers on deleting old “stuff”: code, branches, cloud infrastructure, and services. How do I know this? I often get the opportunity to go into a project that I’ve never worked on or last worked on months ago, and have to figure out its current state so that I can perform a task.
I’ll often find what appears to be old branches, perhaps some dead code, and more cloud infrastructure and services than likely are being used. “I wonder what’s in this S3 bucket?” is a question I often find myself asking, but it applies to all the cloud infrastructure. Since I like to follow the design principle of “elegant simplicity”, I will often try to pare things down and get rid of the old, unused stuff before I embark upon my task. Sometimes I have to do this just to build my mental model of the project.
It’s hard for someone new to the codebase to figure out what is needed versus what is extraneous, although some unused things are relatively easy to discover. Editors such as Visual Studio Code will highlight lines of “dead code” within a file that cannot possibly be executed, and often programmers will comment out lines of code. But if the file contains functions, methods, or classes invoked by code elsewhere in the project, it’s hard to know whether that code is ultimately used. Sometimes there are whole files or directories in the project that appear to be of questionable utility. It’s best if the original authors delete old code when it is no longer being used, and rely upon the software version control system to do its job of retaining a permanent record of older states of the codebase.
It’s not entirely obvious which of these branches are actually needed
Often the software repository for a project will contain more branches than those that are presently being used. Sometimes it's hard to determine what branch is in production, and what branch should be used as a starting point for a new feature. Fortunately, GitHub provides a graphical representation of the branches in a repository which I rely upon heavily, as I describe in ferreting out git branches. I will often work with the developers who appear to own each branch, based on the commits, to see if the apparently dead branches can be pruned.
Cloud infrastructure and services can be even harder to determine if they are currently being used, if they are not well-instrumented. You can get clues based upon naming and the timestamps of when they were originally set up and when various artifacts were created. But to determine if a server or a database can be shut off, you may have to get credentials and poke around inside, to see what appears to be happening.
Quite possibly my favorite button in the AWS console, although it must be used with caution
At this point in its history AWS can probably count on realizing several billion dollars of revenue every year from unused services that their customers have neglected to delete. I envision unused servers sprinkled throughout the racks of a dark AWS data center churning away, perhaps blinking an LED every now and then, while they generate heat and revenue for AWS. AWS does have various services, in particular Lambda functions, that don’t involve a dedicated, continually running server and hence don’t rack up charges when they are not actively being used: billing is purely based upon usage. But AWS customers still incur their own personnel costs in maintaining these unused services.
AWS occasionally discontinues older versions of their services, and forces customers to upgrade in order to keep things running. More than a year ago AWS discontinued the NodeJS v8 runtime environment for Lambdas, and they are now shutting off NodeJS v10. No doubt NodeJS v12 will be discontinued in the not too distant future. So to minimize the developer time needed to upgrade old Lambdas, it is helpful to first prune them down to just those that are being used.
Developer time is money. The longer old stuff hangs around, the harder it is to decipher later, the longer that process will take, and the more developer time (and expense to the company) it will require. It’s best to delete it as soon as you can.