Quick recap before we begin this:

• Verification answers the question “are we building the product right?”
• Validation answers the question “are we building the right product?”

End of recap.

Now that we know what V&V stands for, we can focus on the tools to aid the V&V process. You see, you can’t just go off and do whatever you feel like doing. Even when software development is often a somewhat chaotic process, there’s a bit of organization going on. We’ll talk a little bit about the tools that we use to turn this seemingly chaotic process into something a little more organized.

Version Control Systems

First, there’s Version Control Systems. These help us make sure that we’re building the product right, and if we screw up, this tool allows us to go back in time and pretend that never happened. If you’re a programmer, you’re most likely familiar with Version Control already. If not, or if you’re new, let me explain it to ya. Version Control Systems record changes to a file or set of files over time to make it easier for you if you ever need to go back to a specific version later in the project lifetime.

• Local Version Control System: This is what I like to call a self-managed version control, because it’s basically just you creating a bunch of copies in different directories. If you’re somewhat organized, you might even include a timestamp to identify them faster. Problem is, they’re really, really error prone. If you ever modify a file in the wrong directory, you just lost a version, and if you’re like me, who just lets VSCode auto-open the folder you’re working on, this is a real problem. Also, this only works if you’re a one-man-team. If you’re part of a team, this is absolutely impossible to implement unless everyone works on the same computer.

• Centralized Version Control System: So, in order to deal with the whole issue of working in teams, CVCSs became a thing. These systems have a single “central” working copy of the project in a centralized server, and programmers grab a version, modify it, and commit the changes back to the central copy. If another programmer modified the files while you were working on them yourself, you can pull their changes and merge them before committing them back to the server. As you can probably imagine, this made it a lot easier and faster to deal with multiple people working on the same file at the same time.

• Distributed Version Control System: This is like an iterative upgrade over CVSs. With DVCSs, you don’t only have a working copy of the project, but a copy of the whole repository (a “clone”) in your storage drive with the whole metadata of the original. This means copying the project is heavier, but not so much as to call it wasteful (we’re mostly working with text files after all), and it brings a bunch of benefits with it. You can easily go back to a different version of a file locally instead of contacting the central server each time you need to roll back, and you can more confidently commit changes to your local copy without worrying about breaking the main copy. If changes were pushed to the central copy, you “pull” all the repository changes and history, and if you want to commit to the central copy, you “push” your changes to make them visible and accessible to everyone in your team.

By now, you can probably see how useful Version Control Systems are. They help us keep track of all the changes and modifications we’ve made to each file inside a project, and they allow us to go back if we ever screw up (which we often do), so if you’re not already using a Version Control System, you should probably consider starting to do so. I personally prefer Git, but you could prefer something else.

Tools for testing

What are computers for, if not to make our lives easier? I mean, we’re programmers, so we’re technically in charge of making computers useful for everyone, but that doesn’t mean that we can’t spoil ourselves every once in a while by making tools for ourselves.

Testing, no one likes it (unless maybe if you’re a video game tester, since you get to play the game before anyone else, but even then you have to deal with early bugs and glitches). The solution to this? automation. Why are you still testing your software manually, when a computer can make your life easier? You’re a programmer, you should know better. The less time you have to spend making sure that your code is correct, the more time you can spend stressing about your code not working the way you want it to. That’s why testing automation tools became a thing. Again, these tools help us make sure that we’re building the product right by making sure that everything’s working as it should.

There’s a bunch of test automation tools available. Now, I won’t go into too much detail on these because I’ve never actually used them myself (except for Postman, I heavily depend on Postman when creating web-based applications to test my endpoints. Postman is great, I heavily recommend it). Now, even if I haven’t used them myself, I still recommend that you check them out and try to find one that suits your needs. Test automation is especially useful once a project gets bigger and you can’t manually keep track of everything that’s going on. You can find more information on these tools here, here, and here.

Process administration tools

Process administration is arguably the second most important part of software development (after version control, which is a lifesaver). Process administration is how you keep track of who is doing which task, and how fast they’re working, so they help us make sure that we’re building the right product. It’s not only useful for managers who are looking to keep track of what everyone’s doing, but also for developers who might need help from someone who’s working on another piece of the project. These tools make it easier to know what everyone’s up to without having to explicitly ask them what they’re doing, and if you’re an introvert like me, the less social interactions the better.

Again, there’s a bunch of tools available, and we won’t talk about them all here. The main idea of this blog post is to let you know that they exist, and that they’re actually pretty useful.

Jira is arguably the most popular tool for this. It’s a software management tool that is used by a lot of big companies. It’s very, very robust, and it’s easy to implement in a workspace. Deep integration into the development process, compatibility with other management tools, and a bunch of features that aid the management process are some of the features that attract companies to Jira over their competitors.

Notion is another popular tool that serves more as an AIO workspace. Additional to management features, it can also help with design and productivity, and it supports Markdown Language, which is nice, since most developers are already used to Markdown.

Personally, when I just need a basic tool for managing tasks and tracking progress, I usually go for Trello. It doesn’t have a lot of features, but it gets the job done. If you don’t need anything fancy or deep integration with other tools, you can always opt for this, especially when you don’t have money to pay for new tools.

Remember, always try to find new ways to aid your work process. The less manual work you have to do, the more you can focus on actually being productive. Thinking and coming up with ideas takes time, and we can never take time for granted. Always remember that in order to be more productive, you have to learn how to work smarter, not harder.

There’s this common conception that two heads are better than one, which comes from the intuition that people working in groups are more likely to come up with the correct answer or decision faster/more often than if they were working alone. You see, when you get a bunch of people together and ask them to come up with an idea, it’s highly unlikely that they all have the same idea, right? so there’s an inherent process of brainstorming when people work in organized groups, because everyone has their own thought process and has their own ideas. Parting from there, each individual will either defend their idea, or adopt another person’s idea if it sounds like a better choice. More often than not, the surviving idea or decision will be correct because the arguments favoring that decision are often the most sound.

Okay, sure, that sounds nice and everything, but you already know we’re here to talk about software quality, so what does that have to do with software? Well, it just so happens that software development is a process filled with decisions (button placements, text field vs dropdown menu, algorithm X vs algorithm Y, while vs do-while, etc.), so maybe this conception also applies to software development… and it turns out that it kinda does?

Code review (which we often call peer review) is a software quality assurance activity where someone checks another developer’s code while it is being written. The idea is that there’s a coder and a reviewer, and the reviewer will ask questions about the code and provide feedback on it after a piece of it is written, or sometimes while it is being written, if the reviewer thinks it is necessary (e.g. when the coder is going in a completely wrong direction). This process often results not only in the discovery of quality problems, but also better overall code quality (in most aspects), more defects are found early, more people know how a particular piece of code works (if it needs maintenance and the author isn’t there, someone else can take care of it), increased sense of collective code ownership, better solutions to problems, and more/better QA guideline compliance.

Sounds cool, right? Well, if you like the feeling of someone constantly looking over your shoulder, that is. Developers often prefer sticking to a more toned-down version of peer review, where we ask a teammate to help us review our code only when we encounter a problem, and not through the whole process. Now, since the other person was not involved in the whole development process for this piece of code that you just wrote, there’s often a brief rubber ducking process where you explain your code to your peer, and this also helps the developer clear their mind and look at the bigger picture, which can help them come up with better/faster solutions.

Of course, this process of constant feedback doesn’t only help through the coding process. Thing is, two heads are better than one for pretty much anything: planning, requirements, design, etc. You name it, two heads can do it better (probably). The thing is, what helps us the most is the constant feedback that we get from working closely together. Whether it’s planning, designing, or coding, you most likely will benefit from having different points of view. Having a larger perspective often results in taking more things in consideration, which means that you’ll probably encounter less problems along the way.

In conclusion: yes, two heads are better than one.