Is there such a thing as objectively good code?
Software never was perfect, and it never will be, get used to it. “But why?” you may ask. Well, if we knew why, we’d probably be working on making it perfect, but that’s the thing: we don’t know what the hell we’re talking about when we refer to “Software Quality”. That’s right, today we’ll be talking about software quality and why we, software developers, aren’t its biggest fans (spoiler alert: because we can never seem to achieve it).
Let’s start with probably the most important question: what is Software Quality? Well, it’s an ambiguous term that we like to throw around to refer to writing “good code”. Okay then, when can we consider our code to be “good”? That’s a great question, and I’ll be honest here: I don’t know, but that’s not gonna stop me from trying to explain it to you.
I don’t think anybody knows for sure what good code is. If you go around and ask a hundred software developers to define what good code is, you’ll probably get a hundred different answers. Sure, they might overlap and mention the same key aspects or concepts sometimes, but that doesn’t mean that they’re referring to the same thing.
There is no such thing as “objectively good” code.
I used bold and italics to emphasize and make sure that you remember it, but I’ll repeat it: There is no such thing as “objectively good” code. You can quote me on that. Don’t believe me? Open a new tab and search “Software quality” on Google (or whichever search engine you prefer, I just happen to use Google). Click on Wikipedia’s page and scroll down a bit to the “Contents” section. Under the “Definition” section, you’ll notice that there’s 5 entries. 5 different definitions of what software quality is, and none of them are the same (if they were, there wouldn’t be 5 different entries, duh).
“But Jorge,” I hear you say, “if there’s no such thing as objectively good code, then there’s no such thing as good code period, right?” And to answer this, I’ll use a meme because all this serious talk is getting boring:
I’m not sure if you’re familiar with thermodynamics. I’m not, but Muse happens to be my favorite band, and they titled a whole album after what is maybe the most important law of thermodynamics: The 2nd Law (not their best work in any way, but it’s still pretty good if you want to check it out). It’s a pretty long and complex law that explains why infinite growth is impossible, how energy becomes useless once it’s been utilized, and it uses a bunch of terms that you might not be familiar with, such as entropy, isolated systems, and thermodynamic equilibrium, so I’ll summarize the second law of thermodynamics for you: The amount of unusable energy (entropy) of a system that doesn’t interact with other systems (isolated system) can never decrease over time, and in fact, is always increasing.
“How does this relate to good code and software quality?” Relax, I’m getting there. Think of software as the entropy of an isolated system, and let’s replace “isolated system” with “computer system”. Now we have something along the lines of “Sofware in a computer system can never decrease over time, and in fact, is always increasing.” Now, it’s not really that software is incapable of decreasing, it’s just that we don’t usually go around taking away features and pieces from a computer system (what would be the point of that?). We usually want to add features, not remove them, so let’s make one final adjustment to it, shall we?
“Software in a computer system doesn’t usually decrease over time; on the contrary, it tends to increase”
That’s more like it. Now that we’ve wrapped our minds around that idea, I’ll throw one final piece of thermodynamics knowledge at you before we go back to software quality (I promise this one’s short). Entropy usually lacks order and predictability, and it tends to gradually decline into what we commonly know as disorder. Sound familiar? It should, because that’s exactly what code does; as the amount of code in a project increases, the less control we have over it, and the more we struggle to make sense of what it does, when it does it, and how it does it.
This blog post has been pretty pessimistic, hasn’t it? I mean, we’ve only focused on things that we can’t control, and how bad things get when we lose control over them, but I already knew that would happen. After all, I’m writing it, and if I wanted it to be any different, I would’ve changed it before I posted it. You see, I needed you to comprehend something before I went on to explain how you can make better code: there’s things that are out of your control and always will be, and you need to accept that before you can focus on what you can do instead of thinking of what can’t be changed. You need to let go of what you can’t control to grasp onto what you can.
What can we control then? Well, there’s a couple things that come to my mind right away:
- You can control whether or not your code works. That should be easy enough: does it do what you want it to when you want it to? then congrats, it works.
- You can control if it meets the goals of your project. If your code works but it doesn’t really add any value to your project, then why did you even write it in the first place?
- You can control its readability. If no one can figure out what the hell your code is doing, how are they supposed to maintain it?
- You can control its robustness. In case your code were to fail, does it handle it gracefully, or does everything crash and burn? If it’s the latter, something’s wrong.
- You can control its elasticity. How well does your code handle changes both inside and outside of it? Please don’t go around hard-coding things, I beg you.
There’s a bunch of other things that you can control about your code, but that’s not the focus of this blog post (although, with how much we’ve covered I’m no longer sure that the focus is myself). We want to focus on software quality and how to achieve it. “But didn’t you say that software quality is an ambiguous term?” I hear you say. Why yes, I did, thanks for remembering that. As I mentioned, Software quality is subjective, and while that’s a source of confusion for most, we should consider it a blessing. That means that you have some room to bend the rules, so you can create your own definition and your own software quality standards.
Now, I won’t get into detail about how you decide what you want and what you don’t want your code to be (there’s complete organizations that focus on this) because that would take me way too long, and it probably belongs in its own blog post, so I’ll skip over to the next step. Once a definition and a standard have been decided, how do you make sure that they’re being applied to your code? Well, first, you want to make sure that you adhere to the definition and standards that have been established as closely as possible. Now, while following these standards might ensure that your code is at least decent, it doesn’t actually guarantee that you meet every criteria. For that, you’re going to need some help from these two guys: Software Quality Assurance (SQA) and Software Quality Control (SQC). They sound very similar, and they are, but there’s one key difference:
- Software Quality Assurance makes sure that the quality standards are being met during the software engineering processes that produce products (software). It focuses on the process and ensures that everyone is following proper protocol to create a product that’s up to the established quality standards.
- Software Quality Control makes sure that the products produced meet the quality standards that have been previously established. It focuses on evaluating the software produced and ensuring that everything that comes out of the software engineering processes are good to go.
In short, SQA focuses on the production, and SQC focuses on the product. Simple, right? These two processes are mostly responsible for the quality of the code and software that’s being developed, and while we, developers, like to laugh it off and joke about hiding things from Quality Control, truth is that without them, most of our code would likely be trash (I know you didn’t want to hear that, but someone had to say it).
This blog post is already longer than it needed to be (sorry about that), so we’ll finish it off here. We’ll be talking more about other aspects of software quality in future posts, so you might want to keep an eye on that. As an apology for making this post so long, here’s a picture of a cute cat:
