Why You Need an Independent, Early Code Review

"The freelancer we hired just quit. He says the source code is a total mess and can't work with it. He's not even charging us for his time. What is this? Should I be worried?"

I could hear the stress in my friend's voice. This was indeed a concerning situation. While always ready to assist, I feared that this time I would only be able to confirm his thoughts.

When evaluating software, the first things you notice are its functionality and design. Is it responsive? Does it solve the problem? Does it look good? No weird interactions happening?

But even with all these boxes checked, you're still in the dark about the quality of the underlying source code. Is the code clear, logical, and well-organized? Is it secure and reliable, a solid foundation for future development?

Why is this important?

• You don't want to be vulnerable to hacking, unauthorized access, leaking data, or unavailability.
• You don't want a backdoor implemented that allows the developer or someone else to gain access without your knowledge.
• You want easily navigable code to quickly bring in new developers or let go of the original developers if necessary (worst case).
• You seek conformity, meaning compliance with the coding guidelines. You do have coding guidelines, don't you?
• You don't want future expansions to become increasingly difficult due to an unstable foundation.

Thus, you get the opinion of an expert who evaluates this for you with a 'code review'.

And that review should be completely impartial
Yes, that seems common sense. But I've seen too many cases where the reviewer had connections to the developers or knew someone (often themselves) ready to 'fix' the problematic source code.

Is a code review always necessary? 
A code review isn't necessary for temporary 'throwaway code' or a quick prototype.
This is usually source code that shouldn't be used long-term or built upon.

When should you conduct a code review?
There's no ideal timing, but I suggest having the first review early, such as right after delivering the first MVP or milestone.

You want to know if everything is OK or if you need to get the developers on the right track as soon as possible. Worst case, you want to be informed that you'd better reconsider working with this team.

Announce early that you're planning to get a code review
Being upfront not only shows you're well-informed but also keeps the developers alert right from the start. This should help limit technical debt and encourage proper source code writing.

Developers often feel nervous about external code reviews. They may suggest it's unnecessary because they are already doing internal ones. While that's a commendable practice, it can't replace the objectivity of an independent review.

What will the code review check exactly? 
There are no universal rules for a code review, but there are a lot of best practices.

Most teams have 'coding guidelines,' which are like spelling and style rules for source code. The reviewer will check if the source code follows the coding guidelines.

If there are no coding guidelines, the reviewer will check the top best practices and uniformity. The lack of coding guidelines is a red flag, though.

But coding guidelines don't prevent the production of bad code
Just like it's possible to tell a confusing, illogical story, or even a lie while still following spelling rules.

That's why a reviewer will also assess whether the 'story' of the code makes sense. Is it secure, logical, and well-structured? Is it easy to navigate? Is it not unnecessarily complicated?

So, what have we learned today?

1. Ensure there are pre-agreed 'coding guidelines'.
2. Use an independent expert to assess the quality of the source code.
3. Don't wait too long; it's best to identify issues early so they aren't replicated in new source code.

Don't end up with source code no one wants to work with.
Your thoughts or questions?