What are Code Audits Good For?

Code audits are a low cost, low investment process that will help your project maintain consistency and meet industry standard practices. Unless you’re planning to rebuild your app from scratch, then code audits are a benefit to every project.

Full Transcript Below:

Cris:

What is a code audit?

Cody:

Code auditing prevents us from going down as a bad pathway.

Cris:

You’re looking for the red flags.

Cody:

So we’re looking for problem areas that could produce future problems.

Cris:

Thanks for joining today Cody. I wanted to talk code audits a little bit, so let’s just start by defining that. What is a code audit?

Cody:

So code audit can be a number of things within a single practice of code auditing. For the most part, it is often used during the development process when coders are writing features and et cetera, et cetera, as they push code up and those features get completed, their peers review that to ensure quality of the code base and maintaining standards within that. A lot of the time, programmers, they’re working on very small microscopic pieces of the code and that obscures the macro idea and with code auditing, it makes sure that whatever they’re contributing to the project, it ends up being homogenous with whatever else was going on at the time as the project was architected and that it all makes sense as a cohesive entity.

Cris:

Cool.

Cody:

Yeah.

Cris:

So bringing it down to the Bixly level, why do we do code audits? Why would we do them here?

Cody:

Well, there’s a couple of different things we do with code audits because there’s obviously the development practice that we were just talking about, but then there’s the idea of, let’s say there’s a legacy project that’s coming into our ecosystem, right? If that comes in, we have no idea what’s happened over the last 4 or 5, 10 years, whatever, how long it’s been.

Cris:

Even six months depending on the project.

Cody:

Even six months if it’s been a really active development process [inaudible 00:01:34] a lot of history we need to know about before we say that we can complete anything in any amount of time. So borrowing a metaphor, the idea that if you’re going to buy a house, you typically would want to have an inspection done before you buy that house, which is pretty much a required case for pretty much anyone in that situation, right?

Cris:

Sure, and best practice.

Cody:

And best practice, yes. And then a counterpoint to that much like the same house analogy here, if you want to add a room or any type of large fixture to your house, you typically would get inspections done as well. It’s part of the process, typically the permitting inspections, but tomato, tomato when it comes to that metaphor. But that’s the idea that you’d want to offer inspections both when you get it and when you’re adding to it to make sure everything was done correctly and to code.

Cris:

Gotcha. And so, again, playing the house analogy here, when you get those inspections back, you’re looking for the red flags or the things to be aware of if you’re like, “I know that this house was built X amount years ago, and there was certain coding standards, more building standards,” with this analogy that were not followed, you can look out for those things. So is that the stuff that we’re looking to get back when we’re auditing these legacy style projects, find the red flags, things to look out for?

Cody:

Now for not only that, because that is correct. 100% we’re looking for violations of standards, deviations or things that were considered okay whenever the code was made, “house”, so to speak and that are not okay now because they conflict with certain ideologies, but also, we’re looking for problem areas that could produce future problems. Much like how if you’re getting an edition to your house as we had been talking about, if there’s an issue with how the roof overlaps or something, it may not leak right now but it might in five years. That’s the idea that code auditing prevents us from going down as a bad pathway. It catches us before we’ve invested a lot of time and money into mistakes.

Cris:

Right. You’re using a particular version of angular that might be end of life in a couple of years, or again, this best practice, like you said, was followed and now that’s not the case anymore. It’s not that it’s bad or that it’s wrong, but you have to know how to build on top of that, so that makes sense.

Cody:

Yeah.

Cris:

So these ideals that we’re talking through, standards, looking out for red flags, how do you balance that structure within a project that should be there versus the ideals and overall outcome and maybe market growth of a natural project?

Cody:

Yeah, so it’s a spectrum of sorts. Ultimately, the projects that probably won’t benefit from code auditing and general code review process are typically the ones that are so small that need to go so quick that quality no longer really matters. You just need to get the goal done and you don’t necessarily care about longevity. You just need that thing to work because you need to get to market and as things go, you may have money down the road to just rebuild the whole thing anyway.

Cris:

Okay.

Cody:

If you’re going that fast, you can probably do it quickly with a larger team anyway, down the road. So that project does not really benefit because it’s just going to slow you down and increase your overhead. That said, effectively every other project, as long as there’s more than one team member, because one guy can’t review his own code, will benefit from code reviews in my opinion. In the long run, you’ll prevent yourself from having a lot of mistakes done and making sure that the code is homogenous, so that let’s say, even if you left that dev team or otherwise completely paused your project and then came back to it, months later, the whole thing is homogenous.

Cody:

So when someone goes in and tries to learn how your code base works, it won’t just be, “Oh, they’re learning in this one section,” but then, “Oh, you asked for a slightly different feature,” so then they have to go look at that other code and it’s completely different, so that prevents that scenario from happening so that in the long run, your project is sustainable and can grow with your business at the pace you want. And in addition to that, a lot of the time, if your code is messy, you end up having to spend a lot of time working on very, very small features that seem like they should be done a lot quicker way down the road.

Cris:

Got it.

Cody:

Yeah. So this prevents all those unfortunate scenarios that will strangle longterm project growth.

Cris:

And obviously, because no project is the same and no particular market vertical is the same, you’re still following those standards. You’re trying to keep the ideas homogenous, as you said, to make sure that you can build off it. But I mean, it also is somewhat, I’m sure unique with all these code audits for each project.

Cody:

Yeah, of course. Every project is going to be different. And like I said, there’s variants for the level of, I guess, adherence to the different code standards that there are. And in addition to that, that varies between every project because many projects are made out of both different languages, but also different frameworks and different ideologies within the same framework, there’s a cornucopia of everything. But you just have to follow what makes sense based off of the assessment of your longterm project goals.

Cris:

Awesome. And so, code audits are great. They’re extremely important, and we just have to know that balance that versus the outcome of what you’re trying to do with your company, but it’s really beneficial, so it’s something you should probably do.

Cody:

Yeah, and in addition to it being very beneficial, unlike other areas in the sector that is known as dev ops, which this falls under, much like how unit tests are extremely valuable, but they’re very high effort. You got to write them all. It pretty much, I wouldn’t say it doubles your execution time for features, but it nearly does. Whereas code reviews are just at the end of every feature, someone has to spend 10 to 15 minutes reviewing someone’s code. That is a very low investment for a very longterm and sustainable benefit.

Cris:

So code teams of one don’t generally work with the code audit, you need at least two people.

Cody:

You do need at least two people. It’s like patting yourself on the back if you’re doing your own code reviews.

Cris:

Cool. Any other closing thoughts or insights on code audit? Otherwise, I think we covered most of it.

Cody:

Yeah, I think we did. I think for the most part, the idea is that they’re extremely valuable, they’re low effort and they will maintain your project growth rate as long as you need it, ideally. As long as you’re fulfilling those requirements. So code audits, get them.

Alexandra:

Thanks so much for joining us for that episode of Bixly Tech Tuesday, all about code audits. If you have any questions at all about what we’ve talked about today, go ahead and leave them in the comments section down below. In addition, don’t be afraid to check out our website, bixly.com. We have a free download available on our website as well as in the description below. And you can even sign up for a free consultation with Cris about your next app idea.