November 17, 2015

Behind the Curtain, Part 3: Pruning our Code

Gardening gloves and clippers next to a small plant labeled "HTML"

This is the third in a 3-part series on what we're doing behind the curtain.

When we talk about our Drupal based web publishing platform, we often explain its function as a series of interchangeable lego bricks that can snap into place in a number of different configurations. But often, web software — like the software that runs our GeorgiaGov web platform — is more like a garden than a series of bricks. Over time the code that controls the platform changes; it grows. It has roots that dig deeper in all directions as pieces of code are upgraded and changed to meet the online landscape, to improve functionality, respond to a new web browser, or repair a bug. It has vines that stretch out as we build new functionality — some small little shoots and some strong enough to bear fruit.

As the code grows and changes, it can also “rot” from hidden corners, where no one is looking. Sometimes this happens as old code is unintentionally left to continue running even as newer, better code is currently performing the same task. Sometimes it’s a function that was previously considered the best option, but now there’s a better way. And sometimes it’s, frankly, the result of overworked developers who just missed something, or put in a “quick fix” to get a job done rather than addressing a bigger problem. And so, like a garden, code eventually needs weeding and pruning.

Many Americans experienced the effects of unaddressed code rot this summer, when a number of different software systems all failed on the same day. On July 8, 2015, United Airlines grounded all flights, the Wall Street Journal’s website went down, and the New York Stock Exchange suspended trading, all on the same day. All due, seemingly, to different failures in their software which coincidentally occurred on the same day.

Zeynep Tufekci, in her Medium article, Why The Great Glitch of July 8 Should Scare You, wrote rather insightfully,

The big problem we face isn’t coordinated cyber-terrorism, it’s that software sucks.

Her point is that, left unchecked, code that isn’t well maintained (pruned), is at risk of rotting. Some rotting may not be a big deal, but if the vine your squash is growing on rots at the base, you’re going to have a weak harvest. So how do we protect against those risks on our platform?

Performing a Code Audit

Our GeorgiaGov platform isn’t all that old, relatively speaking — we launched a little over 3 years ago on the Drupal 7 platform — but it still needs pruning to make sure it continues to grow well in the upcoming years. Just as we talk to our agencies about cleaning up their content, it’s time for us to clean up our code. And, just as a content cleanup starts with an audit of your existing content, a code cleanup starts with an audit of our existing code.

Our auditors performed automated and manual reviews of our code, looking at how module and theme code has grown over time, identifying the potential to consolidate and improve the codebase. They provided us with a list of recommended changes — updates to modules, new modules that have come out that can help us tune the platform for security and performance. They found a number of areas where different developers have used different methods of performing the same tasks, and recommended we update them to consistently follow one standard across the platform. There are a few places where we can consolidate code, clean out unused functions, or remove placeholder functions and files. Then there’s my favorite — a recommendation for a tool the developers can all use to make sure they all follow the same coding practices.

Consistently following coding standards can reduce cognitive friction (and save time) when developers work on code written by different authors. (And just like that, cognitive friction is my new favorite term).

Pruning Our Code

The next step was to prioritize the recommended improvements, and build them into our platform roadmap. We’ve run the recommendations through our priority checklist and determined what we can fix fairly quickly, what will take more time, and where the time and effort required won’t provide enough long-term benefit to address the issues now.

Back to our garden metaphor, there are a few ugly weeds that, while not pretty, aren’t hurting anything around them. The cost and effort to pull those weeds is more than the benefits we’d get out of it. Some weeds we can pull out ourselves pretty easily in a couple of afternoons with some elbow grease. Then there are some bigger issues that require calling in a landscaping company to take care of them.

We’ve prioritized the things that will provide performance or security gains for our users, make it easier for developers to maintain the platform going forward, or generally improve the health of our system. This should keep the system healthy, easier to maintain, and provide an overall better experience long term for our customers and constituents.

These types of improvements to the platform are invisible. Our website visitors and content managers likely won’t even notice them, and that’s exactly the point. We’re scheduled to implement the first round of code cleanup in the next few months. So if you subscribe to our newsletter, you will see some of these updates listed in the release notes we send out after each code release. The garden will keep growing, we’ll keep pruning, and you can keep enjoying the harvest.

I think that acorn squash looks about ripe…

 

Related Links:

Related to: