The most basic objective of a coding team is to produce quality code. The code is the is the foundation of the product or system that you’re trying to deliver, and like a structure built on a weak footing, the entire project could find itself in jeopardy if an early mistake is not picked up.
With the pace of the tech industry ever increasing, the task of delivering quality code is becoming more and more difficult. Outside pressure from product owners and managers — who are simply relaying the pressure that they feel from the company, customers or competitors — can cause work to be rushed, and mistakes to be glossed over.
So how do coding teams ensure that they continue to produce quality work, no matter the circumstances? We spoke to three professionals in the field — Kate McInnes, Secure Code Manager at Telstra, Saket Rao, Test Lead at ING and Mick Heywood, Tech Lead at AgriDigital, to find out how they tackled the quality question.
To understand how to deliver good code, we must first understand what defines good code.
For Rao of ING, all quality code shares the following traits:
It’s a definition that is shared by AgriDigital’s Heywood. “Good quality code fulfils the requirements it was written for, is reasonably easy to understand, is tested, and where possible follows well understood design patterns.”
This last point is key, because as Steve McConnell pointed out in his seminal coding textbook Code Complete, good quality code must be, above all else, maintainable.
It’s important to understand that code quality assurance begins with its author — an obvious point perhaps, but one still worth making. The code author shouldn’t rely on reviews, automated tasks, quality assurance or user testing to pick up errors; when a pull request is opened up, the code, to them at least, should be complete.
But assuming that an author has done all that they can to deliver code that is accurate, how does the rest of the team best check for quality?
For McInnes, Telstra’s Secure Code Manager, quality control “can be broken down into two key categories — automated code review and manual code review.
“An automated code review enables you to get velocity and scale. A manual code review will enable you to look for other types of issues, such as business logic, which an automated tool won’t be able to identify.”
Rao also takes a two category approach, but instead focuses on functional and technical quality checks. “Functional checks should ensure that business requirements are met, while technical checks should ensure continuous delivery without impacting code quality.” Rao and his team perform these quality checks regularly over short spans to avoid bottlenecks.
Along with short and regular technical reviews, Heywood and AgriDigital take a communal approach to quality assurance. “I believe having the team sitting together and completing walkthroughs of their test cases fills in a lot of gaps at the very beginning of sprints. This inherently embeds a functional quality check into the code.”
A group dynamic serves to nullify a common trap that lone reviewers often fall into — assuming the author knows more than them. If a reviewer doesn’t understand the code, the pull request should be rejected. It’s crucial that the reviewer seeks clarification. Sure, it could be that they simply didn’t understand the code, but it could well be that the author made a mistake within that code.
Finally, we come to the most difficult part of the code quality conundrum: striking the perfect balance between delivering work efficiently, and getting it right.
It might be a blanket statement, but product managers and owners aren’t usually concerned with code quality — they’ve got other things to worry about. Be that as it may, code quality shouldn’t be an optional extra — it should be a prerequisite. So how do you guarantee quality code while managing exterior time and resource pressures?
To handle this balancing act, Rao and the team at ING have developed processes that see efficiency and quality linked arm in arm.
“Regular feedback on the code is very important to ensure good quality and fast delivery. We emphasise starting the sprint by identifying high level test scenarios, and using walkthroughs as a technique to get the most out of it in less time. This ensures that team understanding is common on what needs to be added or changed.
“We take around 60 minutes for a set of 5–6 user stories. Team members then start writing code and automated test cases in an incremental fashion, which allows us to build, deploy and test the code almost every day.”
For McInnes, developing a culture with code quality at its core comes down to investing in their developers. McInnes and Telstra know that university doesn’t teach culture and work ethic, let alone many of the basic technical skills require in the real world. Incubating talent and investing in their professional development are integral to getting the quality/efficiency balance right.
When all is said and done, managing code quality in today’s tech environment rests on creating a quality focused culture. While tips and tricks from experts are all well and good, what’s more important is that both your dev team and your entire organisation see quality as a fundamental building block of success.
There are no shortcuts to consistently producing quality code. You need systems and procedures that are at once firm and pragmatic, talent that is capable of delivering, and a good level of understanding between your team and your company.
But for the team who can get all of these ducks in a row, the rewards are more than worth the effort.
Looking for your next opportunity? Browse our latest engineering jobs.