How a code audit can rescue and build on your software

A code audit is a rare do-over in business, a chance to look through your existing codebase and make it better based on what you know now. Just like rehabbing an old house, code audits allow you to save everything that’s working and build on that, instead of scrapping the lot and starting from scratch.

This means they can be the best way to squeeze value out of what you already have.

Code audits are one of the three ways we get to know new partners here at TXI. Inceptions let us collaborate with businesses to brainstorm and scope out new solutions. Product Design Workshops let us test new product ideas on real users. And code audits let us examine existing software and hosting environments for source code vulnerabilities, security weaknesses, current best practices and overall integrity. All three strategies let us learn about our partners’ businesses so that we can build for what’s next.

Want to get started? Check out our services.

Jump ahead to:

• Deciding if you need a code audit
• Backend code audits
• Frontend code audits
• Infrastructure audits
• Code audit tools
• What you get out of a code audit
• What happens after a code audit

What is a code audit?

A software code audit is a specialized code review where we analyze your software’s architecture to determine how well it will work for your business. We’re looking for things like out-of-date tools, security risks, unnecessary complexity that could hide bugs, and missing best practices that might hint at deeper problems. There are three basic types: backend code audits, where we test the code that makes your software run; frontend code audits, where we test the code that powers your user interface; and infrastructure audits, where we test the systems on which your code runs.

The things we’re looking at will change, but with all three what we're really trying to figure out is whether your current software can handle the future of your business. The results are twofold: a list of updates that will get the product in line with current best practices and an estimate of what it will take to make them.

Why do we do code audits?

Generally when we’re starting an engagement with a code audit, our new partner has an existing codebase that’s working. What they want to know is how much longer it’s going to work, either because the code they have is shaky or because they want to grow. Sometimes things are mostly fine, and we just need to make a few tweaks for stability and scale. Other times there are major updates that need to be made. In either case, the company is facing a barrier to change, and they need to find out what needs to happen to move forward.

Unlike with an Inception or Product Design Workshop, we’re not looking to change the business model or functionality following a code audit. We’re either taking over support and maintenance for an existing product or we’re preparing to build something greater on the foundation the business already has, and we need to better understand what that is.

With a client like Vibes, a mobile marketing company, we were simply assessing what it would take to upgrade to a new version of Ruby on Rails so the company can scale internationally. For Cobbler Concierge, a startup offering on-demand shoe and handbag repair, we were coming on board to run development for the website and operations management system. We started with a holistic performance assessment of their software and infrastructure so that we could build a strong foundation for Cobbler's future business needs.

How to know if you need a code audit

A good rule of thumb is that if you’ve had software sitting on a stale server for two years or more, you should really have someone look at it. At that point, it’s likely using code that’s out-of-date and therefore no longer receiving security updates for new bugs. For example, Ruby and Rails, two of the tools we use most often, have very specific rules around which versions get security patches. Gems — the pieces of reusable code Ruby developers use to build most standard functionality — also need to be updated, sometimes with a newer version, sometimes with a different, better Gem. If no one’s been checking for security issues and making updates, you’re risking vulnerability.

Beyond security and stability, there are a slew of user experience reasons you may need a source code audit. Best practices on the web change rapidly, and a frontend software audit will let you catch speed issues and outdated user interactions. For example, responsive design, a flexible layout approach that ensures websites scale from desktop computers to mobile devices, didn’t exist even just a few years ago. Now it’s effectively mandatory.

Having a regular code audit process is especially necessary for mobile applications, where “fastest and best” is the minimum bar you have to clear to get user adoption. Because the operating system changes are so major and so frequent — and because you just look bad if you don’t have the latest user interface features — you should consider doing an Objective C, Swift or Java code audit on your iOS or Android applications if the code has been untouched for more than a year. Swift, Apple’s new language for iOS apps, especially needs looking at, because its core language is still changing rapidly.

What the code audit process looks like for our clients

At TXI, we build value by understanding the whole business. Collaboration is always a part of our engagements, but code audits are one of the few things we do on our own, and therefore one of the least time intensive for our clients. We just need access and context. Access to a full repository — where we can see the history of the code — is the best option, though we can also work off of a snapshot. Then we’ll start combing through the code and asking questions.

Ideally, there will be someone on our partner’s team who can offer context for the code. An owner can help us understand the business cases for why code was written the way it was. If there’s someone with technical domain knowledge, like a CTO, who can also answer questions about the deeper technological reasons for building certain features certain ways, that’s even better. A code audit can push your product forward with almost no extra strain on your team.

What we’re doing during a backend code audit

Our backend code audit service takes us deep into your code and database so we can assess the complexity of your code, determine its stability and find any potential security risks. When we audit code, we’re looking not just at your code quality, but at the entire ecosystem of what your codebase talks to and what talks to your codebase. We always start with a fairly standard code audit checklist. One of the first things we check is whether your code has any dependencies on out-of-date tools — for example, if your code depends heavily on the internals of an older version of Rails, or a Gem that’s no longer supported by the newest version of your framework. Things like that will make it complicated to upgrade.

Then we look at the code itself. We want to know if the code is idiomatic — if it was written by someone who is familiar with the community standard structure and layout. If the code doesn’t conform to surface-level best practices, that’s a good sign there are surprises buried deeper. We run tests and use tools that inspect the quality of the code, so we can see where any pitfalls may lie. Looking for patterns and lines of code that seem to hide complexity can help us find something called “code smell,” which is just a developer’s way of saying the code has signs of deeper problems. The closer the code hews to standards, the more stable it’s going to be and the easier it’s going to be to build on it.

Once we’ve analyzed the basics of your code, we can focus on areas that might be particularly important to your business, like how an API is set up or whether there are additional security issues.

What we’re doing during a frontend code audit

With a frontend code audit, we’re really looking at the code that’s going to affect user experience. Right now, that’s primarily two things: site speed and responsive design. Those are two of the biggest needs in web design right now, so they are what we’re most often auditing for, though newer features are always cropping up and working their way into the audit process, like Google’s Accelerated Mobile Pages. When we’re looking at site speed, that’s really a performance audit. We’re testing the site to see how well it performs the jobs it needs to do: Is it calling too many unneeded files? Is it using images and font sizes that are too big? Is the structure of the code interfering with the page load process? All of those issues can slow load time, which can lead to usage dropoffs, lower conversion rates and less money for our partners.

Our frontend audits also include a search for reusable code. See how that can help your developers, designers and users.

With responsiveness, we’re trying to find out what it’s going to take to get a webpage to properly size down to mobile. Some of that is looking at the code, finding out how things are organized and where things break down. But it also requires looking at the design and the information hierarchy, so we know how things should work on mobile to accomplish the same goals. Older sites weren't built with any of this in mind, because users didn't visit from their phones. They were simply built to look one way on one size always. It's a matter of trying to understand the domain, the pages, the flows, so that we can make an educated decision about how to structure things going forward.

Improving site speed and creating mobile-friendly pages isn’t just about helping your customers use your site. It also helps them find your site. Google is increasingly assigning SEO value to user experience. So if you want your site to rank high in search, it needs to be speedy and work great on mobile.

What we’re doing during an infrastructure audit

An infrastructure audit is a little different than frontend and backend code audits. Instead of focusing on the codebase itself, we’re analyzing how the DevOps team runs that code on your network of servers. It may be a different direction to look, but we’re still testing some of the same things, namely security and site speed. A weak server infrastructure is just as much a point of vulnerability as weak code. We make sure your setup is architected securely and your servers are running up-to-date software so there aren’t any potential security risks.

Learn why an infrastructure audit means something slightly different at TXI

An infrastructure audit is also an opportunity to see if the systems are running efficiently. The frontend code audit improves site speed by setting up the software to only pull what it needs off the servers. The infrastructure audit improves site speed by insuring those servers can deliver as fast as possible. We can also use it to make updates to the site run faster by analyzing DevOps practices and finding opportunities to speed up deployment times.

There is one thing infrastructure audits do that backend and frontend code audits rarely manage: put money back in your pocket. Infrastructure comes with a recurring price tag, whether it’s for running servers or securing space in the cloud. When we look at your setup, we’re also checking to see if you’re paying for more server resources than you need. Frontend and backend code audits are meant to save you money in the long run and earn you more money from happy users. But if you’re running more cloud or servers than you need, an infrastructure audit can reduce your monthly bills right away.

Code audit tools

The best code audit tool we have is our own experience — particularly when it comes to audits that involve design elements, like responsiveness. With both frontend and backend, our code audit strategies pair manual analysis with code auditing tools that identify potential problem areas. On the backend, Reek is a tool that detects those “code smells” we talked about. When we have access to our partner’s entire repository, we’ll usually run a tool like Code Climate that analyzes the code for complexity and duplication, and checks to see if the developers wrote tests to validate their code.

Security testing has a few specialized tools. Bundler Audit checks to see if the Gems your code depends on have security warnings. Deeper into your software, Brakeman checks the structure of your code for potential security weaknesses. We can take the list it spits out and check each item for vulnerabilities to exploit, even trying to hack it ourselves. Pairing these automatic code review tools with our own manual review lets us quickly learn what it will take to get your code up to current standards.

When we’re looking at responsiveness or any other kind of user interface feature, there’s no better tool than our own eyes. Site speed, however, is very different, because there are hard numbers associated with success. We often use a tool called Webpage Test to find out how fast the site is and where it’s failing. That way, we can set a baseline speed and then track how much of an improvement each change to the codebase is making.

What you get out of a code audit

When we’re done combing through your code, you’ll walk away with a code audit report that tells you exactly where your vulnerabilities lie and an estimate of what it will take to get your code up-to-date with the latest best practices. Sometimes we’ll find that the tests which validate the code’s integrity were poorly written, or slow, or don’t exist at all. Often we’ll find that you’re running out-of-date versions of things that need to be updated. The most common scenario, though, is that we’ll just find that there are better solutions for the problems your code is trying to tackle. Software is constantly improving. That’s why we love it. It’s also why we’re always finding and testing new tools, so we can make sure our clients get the best possible solutions. A code audit is an opportunity to apply all those tools to existing code, so it functions as well as it can for as long as it can.

What happens after a code audit

A code audit is almost always the start of something else. Sometimes we do simply find that everything’s great and we can say, "Yep, you passed. Here's your sticker." But if we’re doing a code audit, chances are our partner is looking ahead to a planned upgrade, or to add a new feature, or to make security improvements. We’re using the code audit to estimate how much time and money that next step is going to take and why. So instead of just saying something will take a few weeks, we can say it’ll take a few weeks because of dependencies, or a weak server infrastructure, etc. After a code audit, we can make a plan for the future of your business, starting with a stable and secure codebase.

Interested in growing your business? Let's talk.