As developers we take a great deal of care to ensure that we don’t write bad code. I think this is something we have seen from the youngest intern to the most experienced dev in our company.
We see that code every day and naturally, when you care about it, it's annoying to see it in a bad state (no matter who wrote it).
I consider myself a self-taught developer. Having spent a good amount of time doing freelancing before starting my company, I understand how hard it can be to learn and do everything right, in a structured way, so that you don't have to struggle with maintaining quality while still staying agile for the client.
From a developer perspective, I’ve seen a number of points of view when assessing quality:
- The "I’ve found a solution" view where the review stops when the problem has a solution implemented.
- The "It’s quality code because I use a code standard view" when the only thing checked is how the code looks or is structured.
- The "Design patterns" view where if you use some of Martin Fowler’s design patterns you can consider that the entire project is of very high quality.
- The "No bugs approach" where the quality is represented by how few bugs are found in the functionality.
From the perspective of the client or the PM, I usually see three views:
- "Can we launch yet?" view where you want to ship anything as soon as possible.
- "Done without any bugs" perspective, where the end product has to be perfect to consider it meeting the quality standards.
- The "Number of bugs after a developer says it’s done" optics in which quality is measured by how many bugs are found after all features are implemented.
As you get more and more experience working in this field you realize your own views in the matter can be limited - if not biased. Without a kind of 360 view of the topic, we can’t try to reach a level of quality that you see in Fortune 500 companies.
Of course the answer to what quality represents is somewhere beyond an individual opinion. It spans over the entire development process starting from the first client interaction to the months after the final release.
How can a team improve quality - from development, to release, maintenance and client interaction?
What I'm focusing on with my team this year is finding tools to automate and ensure good code by adhering to code standards, adopting best practices and constantly learning about what quality code looks like.
At Around25 we've begun to understand what are the characteristics of quality from every perspective, then changed our entire approach starting from the first contact with a client through to the launch of their product and beyond. How do they feel about this? You can read a bunch of reviews on our clutch profile (click below):
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:
- Document everything
- Adopt code quality standards
- Make a Verification Checklist
- Automate checks and releases
Any attempts to drive change inside an organisation will probably fail if these changes are not properly documented, distributed and adopted by team members.
Therefore the first steps you need to take as a team is to start writing documentation for how your team should function.
Without a first step towards documenting the best practices everyone will have their own way of doing things 'right' and that adds overhead and makes things unclear within the team.
This documentation has to be easy to understand by everyone in the team and contain sufficient information so that most questions one may have regarding a subject to be already described in your content library.
Adopt Code Quality Standards
Taking a look at the answers given by our developers to the survey we see 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.
If you start every project with a standard you can not deviate from, not only will you ensure other devs follow the same process, but you can prevent bugs before they slip into the code and make you spend more time reproducing and fixing them.
Having a predefined way of doing things is not just related to code, but also to management, sales and business. It allows teams to move faster and with more confidence. It’s also a great way for the more junior members of your team 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:
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.
For us it ultimately comes down to a simple checklist of yes-and-no questions that every PM or client can assess with the team.
Our checklist contains questions like these:
- 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?
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.
Soon, we will send the complete contents of these checklists and some more ways to improve quality to our blog subscribers so be sure to sign up after reading the article.
Automate checks and releases
Another great way to ensure quality in a project is based on how many tasks are automated versus manual. 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.
At Around25 we introduce automation from the first lines of code we write. This helps make the whole development and release experience painless. How does this work?
First, automation through a simple pre-commit or pre-push hook.
This allows developers 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.
Moving Forward Towards Quality
We face challenges every day; from delivering projects within tight deadlines to adapting to working fully remote due to Mother Earth throwing a curve ball, but quality should not be one of them.
Simple steps adjusted to your own assessment of what it means to deliver a quality project can go a very long way towards improving your team.
This article has an interesting timing.
It comes right after we at Around25 had a hackathon to discover new ways of improving code quality.
It also comes in a year where we decided our whole company should focus on seeking quality in all departments.
And, along with working hard towards improvement and ensuring code quality within our team, we started to look for the same quality standards in the people who will join us.
I would like to end with a simple question:
What is your view on quality?
Give us your answer in the comments section below and we can have a constructive discussion on an aspect that matters a lot to us.
*Reminder: we want to share our quality checklist with our blog subscribers. Be one of them and subscribe below.
If you have any questions regarding any of my articles feel free to send me an email at: firstname.lastname@example.org