How to Spot High Quality Code
There’s a significant difference between “code that works” and “high quality code”. It really comes down to how you want to spend your time (and money). You can rapidly write code at the beginning, but changes and bugs are harder to fix down the line. Or, you can invest time in the beginning and have a project that is stable and usable for a long time to come.
Full Transcript Below:
Cris:
What is the difference between code that works, versus high quality code?
Cody:
There’s definitely often more than one way to do the same job.
Cris:
Whereas code that works, it’s more of a, “It works, but for how long?”
Cody:
Who wrote this, who wrote this stuff? It was me.
Cris:
Yeah.
Cris:
Cody, good to have you in the studio again.
Cody:
Always. Glad to be back.
Cris:
Yeah. So today we get to talk high quality code.
Cody:
Oh, okay.
Cris:
Yeah. So what is the difference between code that works, versus high quality code? Because, I think those are different, and why does that matter?
Cody:
Yeah, definitely. So when you are an engineer, let’s go from the software engineer’s perspective here, there’s definitely often more than one way to do the same job.
Cris:
Okay.
Cody:
To attain a certain business goal, to write a feature, to implement a page. There’s oftentimes a lot of different qualitative difference in the different ways you can choose to go about actually completing such a task. And the differences between the idea of high quality versus the opposite of that, which what I would call quick, or historically known as “cowboy coding”, is that a high quality implemented feature would be one that is both future-proof and forward-thinking, and I guess, the core term would be maintainable.
Cody:
So, when we go down to what that means in terms of qualitative areas in the code, that would be commenting, good structure, keeping it simple, even the areas that are complex. Sometimes even though you can write something super condensed, and from your perspective it is a very neat and concise thing, that can sometimes hurt readability for someone who doesn’t have the context as an engineer coming in later in the game.
Cody:
So, speaking how that benefits and why we would care, let’s say for someone who is a product owner or a stakeholder in the company-
Cris:
So, stakeholders, this seems like something that they would probably want to care about. They want quality code versus code that works.
Cody:
Yeah.
Cris:
So, how do stakeholders come into this and why do you think they would care about this kind of stuff?
Cody:
I think the biggest reason is that you can get things done quickly with quick- And quick and dirty code, specifically is what we’re getting at. Because obviously we want everything to be as quick as reasonably possible to get done. But the reason you want to at least put some forward thought and a little bit of investment into that quality aspect of code, which would be commenting and good structure and all the stuff mentioned previously, is that you need your code to be future-proof for your own engineering teams.
Cody:
And chances are, you’re going to have to tell your guys to come back to an area of code someday in the future. And when they do that, if it was done quickly in the beginning with no comments, it’s just slapped together, it’s going to take exponentially longer for every feature you layer on top of that area.
Cody:
So you’re going to oftentimes, and I’ve seen this numerous times within both contracting and just projects we’ve inherited where someone needs a simple, simple task done. Like, “Hey, can you edit the title on this page?” Or something similar to that. Nothing special.
Cris:
Sure.
Cody:
And because of legacy decisions, things that happened before the current software engineering team has touched it and things were slapped together, it ends up taking way, way longer than expected and no one’s happy about that.
Cris:
No.
Cody:
Because obviously it’s like, “Well, are the programmers being bad?” Or, “Is it because of XYZ reasons?” And ultimately, it’s because quick code decisions were made early and now you pay him for it later. So, you can choose to have more of a product stability of knowing, “Yeah, these things will take a little longer because we have some practices we need to do for keeping things high quality,” but it will be a predictable process to implement throughout the life of the project.
Cody:
Whereas you can do it quickly, and you’ll have quicker output in the beginning, but it will exponentially increase as you near the long-term aspects of the project. And it becomes an unpredictable nature of how you would actually budget and account for time for even the most simple of features.
Cris:
Gotcha. So bringing it back, it sounds like we started with code that works versus quality code.
Cody:
Yeah.
Cris:
That quality code, there’s a lot more parameters that go along with doing the quality code, whereas code that works, it’s more of a, “It works, but for how long and how far into the future?” Obviously we’ve talked a bit about a lot of these different, I think, descriptive factors that build into quality code, but let’s lay those out. What are those things that you’re looking for in the quality code? We touched on them all over the place, but let’s kind of make the bullet list. What are you looking for in quality code?
Cody:
Yeah. So, there’s going to be a couple of different subsections to this. There’s going to be for one, general code practices. Which would be, you need comments, obviously. You need documentation. Write out what things are doing and don’t just expect the code to document itself because we may think that, even software engineers fall into that trap, and I’m guilty, too, but we have to discipline ourselves to document what we’re doing, especially the complex areas, because we’re going to forget our own context. And I know I’ve come back to projects years later and had to touch something and been like, “Who wrote this?”
Cris:
“Who wrote this stuff?”
Cody:
“It was me.”
Cris:
Yeah.
Cody:
And from there, you need lots of documentation to avoid those scenarios. So that’s the first big thing, documentation. It’s a really easy thing.
Cody:
The next part is obviously clean and concise actual code structuring is a big part of that. And down on that same subsection, but a really big, I call it a fuzzy area, is architecture. Having someone who has experienced within whatever paradigm or platform you’re using; Python, Django, or Node.js, that kind of a thing, having someone who has the experience to know what can go wrong if you architect something incorrectly in the beginning and how to avoid that is an incredibly important aspect. Probably the most important aspect.
Cris:
Okay.
Cody:
Because small code changes, documentation, those are things that can be fixed over time if they were done wrong in the beginning. Architecture sometimes means a complete rebuild, means doing the whole project over again, and no one wants to be in that scenario.
Cris:
No, definitely not.
Cody:
Yeah. And so, those are just a quick couple three points on how to maintain some decent code in the first section. But the second subsection is dev ops practices.
Cris:
Okay.
Cody:
Things like continuous integration, which is basically every time someone makes a feature, test it immediately. Don’t wait for the milestone to be done, test it now. As often as possible, as frequently as possible, so that we know what’s going on and are able to solve it while the problem is small.
Cris:
Gotcha. Okay.
Cody:
And then the next feature of that would be coupled into a continuous integration, would be automatic testing. That’s always a great aspect of how to improve code. Write things that validate it’s working. That’s a pretty good aspect, and probably one of the more important parts of that.
Cody:
And then the last blanket, again, another qualitative fuzzy aspect, much like how the first section had for dev ops would be, just general developer discipline, of the idea of keeping consistent commit logs, keeping feature branches labeled accurately, documenting within tickets in your project management suite. Things like that are what lead to good code, which seems counterintuitive because it’s meta information of the code, it’s not actually the code.
Cris:
Sure.
Cody:
But to have that all strung about as the foundation and scaffolding that holds up the project that would otherwise just be a bare scaffold of sorts, to repeat the word, that’s an incredibly important aspect. And I think that comes down from project management, from the dev ops, from basically everyone involved. And of course, the software engineers have to deliver on the promise of that discipline and actually follow through with that. That’s a really important aspect.
Cris:
That’s cool. So we’ve touched on it a lot, obviously. Any final thoughts and closing on this? Code standards, PEP8? I don’t know anything of…
Cody:
I think it’s important to not mention too many specific details because ultimately every project is unique and different and that’s something that I think can be derived from whoever would be a senior developer or a CTO who has some experience in the actual under workings of the project, per project.
Cody:
And also, none of this is concrete. It’s not like there’s a 100% list every project should follow. It does depend on how fast you need to go. If this is a project where you do not care about its long-term aspects and you just need something like a quick and dirty microservice because you need a stop gap solution, a lot of this stuff won’t apply.
Cris:
Got it.
Cody:
But that is very scalable. And if you need something that’s enterprise grade that is reliable, you’re going to want to follow these practices. So, just to wrap that all up and put a bow on it, when it comes to quality code versus quick code, you can either pay it later or you can pay it now, but the time will be paid for the code-
Cris:
Regardless.
Cody:
Regardless, yeah. Whether it’s quick or high quality, it’s going to end up being very similar. The difference is that the high quality code will have a predictable pathway of execution and completion…
Cris:
And financial.
Cody:
And financial, of course.
Cris:
Predictability.
Cody:
Because time is money, right?
Cris:
Ultimately.
Cody:
And the quick code will start quickly and ramp up over time. And that’s just the nature of planning and doing anything that’s complex. If you had an engineering project and did not necessarily plan and just started slapping together an engine, by the time you fit everything together, it’s probably going to be really hard.
Cris:
It’s going to be really bad.
Cody:
Yeah. So, follows the same idea. And with that, that’s all I got.
Cris:
Cool. I love it. Well, appreciate your time, Cody. I think this made a lot of sense and put forth a really good argument of why just because your code works, may not necessarily mean that it’s of a high caliber of quality.
Cody:
Correct.
Cris:
Yep.
Alexandra:
Thank you so much for joining us on this episode of Bixly Tech Tuesday, where Cody and Cris talked about how do you spot high quality code? What are you looking for, and what are some of the attributes besides, “Does it work?” that code should have as part of your product for your end users. And don’t forget to check out the special links that we have for you in the description down below. You can find a link to our free custom software guide, which will walk you through the steps of getting through planning your own custom app idea, whether that be for web or mobile or both, whatever your solution might look like. You can also check out our website, Bixly.com. And at the very top of our website, there’s a button that says validate your app idea. If you click that, you can schedule a free meeting with Cris. 60 minutes to talk about your app idea and we’ll point you in the right direction. Until next time, this has been an episode of Bixly Tech Tuesday Tuesday.
Originally published at https://blog.bixly.com on August 31, 2021.
