3 Steps to Ensure Code Quality in Offshore Software Development

I’m sure you agree with me that when we are about to work with an offshore software development company, code quality is something we typically worry about.

Well, this is the case every time we work with an external partner.

The thing is that you shouldn’t expect less or more form your offshore or onshore team. Consider them as a different project team in your company.

But there are the challenges:

• How do you ensure that your offshore team is doing the right thing (delivering what is expected)?
• How do you make sure they do things right (delivering quality)?

Here’s the kicker:

You need to use similar methods to ensure code quality when working with an offshore software developer when you work with an in-house team.

This guide is here to help.

Keep reading and you will see how to avoid misdelivery and ensure the code your offshore team delivers meets your quality standards.

HOW DO YOU DEFINE CODE QUALITY?

Code quality is a vague definition. What do we consider high quality and what’s low quality?

Code quality is rather a group of different attributes and requirements, determined and prioritized by your business.

These requirements have to be defined with your offshore team in advance to make sure you’re on the same side.

Here are the main attributes that can be used to determine code quality:

• Clarity: Easy to read and oversee for anyone who isn’t the creator of the code. If it’s easy to understand, it’s much easier to maintain and extend the code. Not just computers, but also humans need to understand it.
• Maintainable: A high-quality code isn’t overcomplicated. Anyone working with the code has to understand the whole context of the code if they want to make any changes.
• Documented: The best thing is when the code is self-explaining, but it’s always recommended to add comments to the code to explain its role and functions. It makes it much easier for anyone who didn’t take part in writing the code to understand and maintain it.
• Refactored: Code formatting needs to be consistent and follow the language’s coding conventions.
• Well-tested: The less bugs the code has the higher its quality is. Thorough testing filters out critical bugs ensuring that the software works the way it’s intended.
• Extendible: The code you receive has to be extendible. It’s not really great when you have to throw it away after a few weeks.
• Efficiency: High-quality code doesn’t use unnecessary resources to perform a desired action.

A quality code does not necessarily meet all of the above-mentioned attributes, but the more it meets, the higher its quality. These requirements are more like a priority list that depends on the characteristics of your business.

If you get excited by quantitative measurement and want to put metrics behind code quality measurement, you could apply the following software metrics:

• Weighted Micro Function Points
• Halstead complexity measures
• Cyclomatic complexity

According to the State of Code Quality 2016 survey, the top 3 ways to ensure code quality are:

• Regular code reviews
• Unit testing
• Functional testing

 In fact, half of the respondents are doing meeting-based code review and 72% of them are doing “over the shoulder” code review while 63% of the respondents are doing tool-based code review

In the following part, we will show you how to hold regular code and progress reviews with your remote team to ensure they do things that matter in the desired quality.

CODE QUALITY IN OFFSHORE SOFTWARE DEVELOPMENT: BUILDING A SYSTEM

1. SET EXPECTATIONS IN ADVANCE

Once you have a list of the most important quality attributes, you need to make sure that you’re on the same side with your offshore software developer. Clear requirements and a consistent system will make sure that the delivered code quality is good and there is no misdelivery during the project.

Sit down with your team and answer the following questions:

• What quality attributes are the most crucial for the project?
• What are the most important product requirements? (It has to be well-defined, prioritised and easy to understand for everyone).

The output should be a prioritised list with exact expectations and requirements. 

2. COORDINATION

One main channel

Even if the rules are clear for the project’s stakeholders, you need a system that makes everyone accountable and provides a platform to frequent communication.

 First, there needs to be a platform available for every stakeholder of the project. This channels every communication that could take place between the project team members. Forget emails; there are much better tools for team communication.

Two years ago, we fell in love with Slack. It’s a messaging app for teams that organizes team communication into different channels based on topics, projects or teams. Slack can be integrated with other tools such as GitHub, JIRA, Trello that gives an additional productivity boost to the team.

It’s really effective to address every product-related issue that arises between meetings. This is a great way to ensure that everyone is involved and updated about the project’s current state.

Regular meetings

Google hangout is a free solution for screen sharing and video conferencing. Skype is also a good alternative. Apart from using a chat platform, there needs to be a way that provides face-to-face communication between you and your offshore software developer team.

How often should you hold meetings?

We do regular meetings every day and retrospective meetings at the end of every sprint.

Daily meetings: These are daily scrum meetings (usually 10 minutes long) when every team member working on the project answers the following questions:

• What did you do yesterday?
• What are you doing today?
• Are there any obstacles that prevent you from achieving your daily goal?

These daily meetings keep the project super focused and allow the ability to give early feedback on the progress and the quality of the work. These ensure that there is no misdelivery and that every stakeholder is on the same side.

For tracking who does what you can use your project management tool or a dedicated app such as Status Hero.

Retrospective meetings: In this case, we take a bird’s eye view on the project. Seeing the bigger picture gives a better understanding what happened during the last phase.

During this meeting, every team member receives red and green post-it notes. On the red note, team members write what went wrong; on the green, what went well during the sprint.

Cards are shared with everyone and similar ones are grouped together. Every team member can select 7 different issues that need to be addressed and 7 things that went well and should be kept.

Issues and great things are prioritized and the whole team brainstorms on how to handle issues in the future and how to keep things that work well.

It's obvious that you should follow some kind of software development methodology. Here is a post to select the most appropriate one for your team.

3. CODE TRACKING

Thanks to frequent communication, the project will be on the right track, so misdelivery is less likely.

But you still don’t know what’s happening in the black box, inside the software.

This is the most important part of ensuring code quality. This is the virtual way to look over someone’s shoulder and review her code.

The most commonly used software configuration management tool is Git; 43.4% of teams are using it. 

Make sure that your software developer team uses GitHub or another similar code sharing and publishing service. This is a great way to actually see how the remote team contributes to the project and gives a real picture of code quality.

Also, JIRA is the most commonly used tool for bug tracking, with 41.8% of respondents using it.

But it’s more than just a bug tracker tool. It’s also a project management tool for agile teams that has integrated scrum and kanban boards, making it easy to create and manage sprints. It also gives visibility across all teams and projects.

JIRA combined with Confluence (a document and specification sharing tool) gives a real boost to the project. Documents and specifications can be attached to every task, making it easier to oversee the project and avoid getting lost in the documentation.

If you’re hungry for more tools you can use with your team, check out this post.

To learn the differences between using a backlog and a specification, read this one.

CONCLUSION

Frequent communications and code review determine the framework of your collaboration. This framework makes it possible that everyone on the project team is on the same side and also provides tools to regularly inspect code quality.

Using it consequently, misdelivery will less likely occur and horrible code quality can be avoided.