Ensuring code quality as a remote team
Tags: cleancode, remote, automation, productivity
Published: 2020-04-14 18:10:19

---
title: Ensuring code quality as a remote team
published: true
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/wisokqfkh9ufd2k3xee3.png
description: 
tags: #cleancode #remote #automation #productivity
---

Three weeks ago, before the COVID-19 national emergency status was initiated in my country, Romania, we decided that for the good of all our team we would switch to remote work.

Making this decision was not easy, mainly because we like to socialize and get to know each other better. At the same time, it was a good opportunity to test how we can adapt to a 100% remote scenario. Who knows, if we get past this, we go remote for good.

Besides agreeing that everyone can work from home, this situation means all internal processes ensuring *trust, quality, communication and accountability* within our company culture will carry well in this new way of working. You know, making sure that what you considered a fact yesterday still applies today.

While trust and accountability depend a lot on each company's hiring process and the people you already have in your team, **quality can be a bit more elusive if you don’t have a way to assert its outcome and a process to deliver on it no matter the team members involved**.

#The hardest part: getting started

First, I would like to focus more on this aspect and discuss about some of the ways we assess quality inside Around25 for all team members, regardless of seniority level.

If you don’t already have a process to handle the quality aspects of your organisation and you rely solely on the skill of each employee, you should first start by having an open discussion about what quality means to you, your developers, your project managers and your clients, so that everyone (hopefully) understands the whole picture.

As part of this process we did an internal survey seeking to understand the problems people face in delivering a quality project. The variety in perspectives was illuminating, and it helped us define the code quality principles everyone can aspire to:

1. [Adopt code quality standards](#adopt-code-quality-standards)
2. [Make a Verification Checklist](#make-a-verification-checklist)
3. [Automate checks and releases](#automate-checks-and-releases)

#Adopt code quality standards

Taking a look at the answers given by my colleagues, I saw a high response percentage focused on the quality of the code. Code quality defines various aspects of how the code is written and tested in order to:

- Support easy integration of new developers of any skill level with minimum overhead.
- Have a consistent approach to feature development across the entire project.
- Allow for automatic detection of possible or unforeseen errors.
- Adhere to code standards and best practices used in the industry.
- Decrease the number of bugs in functionality visible to the end user through automated tests.

Having a predefined way of doing things is not just related to code, but also to management, sales and business, allowing teams to move faster and with more confidence. 
It’s also a great way for the juniors to be productive fast, learn along the way, and develop a strong foundation.

Here's an example of the kinds of checks that are performed for a Go codebase:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/izxi5z34vt47x6hk5rey.png)

*If the entire team is remote and the normal mentorship done in the office is harder to replicate, having a set of verifiable and enforceable guidelines of how to write good code keeps the project on a straight path.*

#Make a verification checklist

Coding standards, design patterns and unit testing can only get you so far. In order to have a simple and complete overview of the quality of a project we adopted a straightforward process to rate a project quality level from all points of view. 

It's a simple checklist of yes-and-no questions that every PM or client can assess with the team:

- *Does the project adhere to the company code standards and best practices?*
- *Is every release tagged before it is deployed?*
- *Can you easily revert from one version to another without rebuilding the app?*
- *Are your deployments automated?*
Etc.

Since we have both technical and non-technical PMs and clients, this helps put everyone on a common understanding of the current status and the next steps needed. 

#Automate checks and releases

Let's face it, as humans we can be terribly inconsistent. Machines are not. So make the most out of that skill where it matters, using the blessings of automation.

How does this work? First, automation through a simple **pre-commit or pre-push hook**. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/c3blpkbj11oe5dxpz0nz.png)

This allows us to get instant feedback based on custom checks we define for each programming language.These can include:
- code format, standards, best practices;
- checking and executing tests;
- checking code coverage;
- checking the existence of different files or any other custom checks you want to automate.

Once these are added you can also enforce them as part of a deployment pipeline to ensure that no unchecked code will make it into a next stage.

Automation can improve not only code quality, but also developer productivity. For example, while we previously used to build and deploy mobile apps from a developer workstation, now this is done completely automatically by simply making a commit in the right branch.

Most of our git repos use Gitlab CI to accomplish this easily. Every git repo has a somewhat complex **.gitlab-ci.yml** file that **checks all code, runs tests, builds Docker images and pushes them to registry, deploys latest version on a test server or even release new builds into production.**

It's up to your team to understand how to improve their daily work by finding ways to optimize it and eliminate all the recurrent things that take time to do and maintain.

#Thinking long term

In order to get results from any initiative focused on quality (especially when the team works remotely) you need to look beyond one current project and understand how your team would benefit from it on *every* project.

For example this year we held a [4-day hackathon](https://around25.com/blog/rapid-application-development-building-an-app-in-four-days/) focused simply on Rapid Application Development, where teams took a project specification estimated at 3 months development time and tried to finish it from Friday til Monday.

It was clear to everyone that you could not complete it unless you change the usual approach and tackle it from a (sometimes VERY) different angle. 

While some focused on using 3rd party services they haven't used before, and others used new libraries or frameworks to help them gain an advantage while developing the product as they normally would, my team and I focused on finding a process that would allow us to eliminate rework (or bugs)  and generate quality output at every stage of the project.

These 4 days, we lost a few hundred billable hours plus some extra expenses, but if you look at it from another perspective we learned how to improve our estimates and our processes so that we can be more competitive while increasing the quality of our deliverables.

...the things one does for quality.

#Rant over

By integrating quality checks at every point, from the initial specification analysis to the product launch, monitoring and maintenance you can build a stronger team that continuously learns how to improve, regardless of the previous experience of the developer. **And regardless of where they physically do their job from.** 

Building a quality product, whether it's an MVP for a startup or rebuilding an enterprise system is not done by simply finding someone to start coding and following the specification laid out by the client. It's done by adopting a team-wide focus on what quality is, how it can be addressed and improved daily, and how it improves the team members themselves in the process.

Now question time: how do *you* assess code quality (be it individually or within a team)? 

*This article is written by our CTO, [Cosmin Harangus](https://around25.com/blog/author/cosmin/)*.