What is code quality and why does it matter to your organisation?

Most software engineers are well versed in the importance of quality as part of the software development process and the one thing the engineers we work with have in common is a desire to do things right in terms of code quality and testing practices.

So selling quality to engineers is relatively easy. However, a lot of organisations, managers, and leaders still require some convincing and there is a common perception that activities like writing unit tests and refactoring are wasteful activities. It’s still something of a rarity to find senior leaders in organisations who truly understand the virtues of code quality and actively promote a culture that encourages high quality software.

What is code quality?

Code quality is an umbrella term covering a few different areas. At its core, code is simply the unambiguous expression of business requirements in a format that a machine can understand. All that is needed for code to be correct is for a machine to be able to read it, and behave as required.

Getting to that point of ‘correctness’ however, is a significant amount of effort, often involving refining the understanding of a problem. Code must therefore be read and changed frequently by developers, to fix bugs, correct behaviour or extend functionality. Code quality determines the ability of a developer to read the code, understand its intent, and change it. Poor code quality makes this process harder, slowing the rate of development, and increasing the likelihood of bugs and defects.

Some forms of poor code quality are simple to explain and fix, such as poor formatting, or the lack of naming conventions. More complex topics like ‘design patterns’ and principles such as ‘SOLID’ describe how to structure complexity in a way that ensures readability and maintainability.

Why does code quality matter?

Organisations that do not pay attention to code quality and testing practices are taking some serious risks that could have serious implications.

Cyber crime is on the rise and there have been a number of high profile hacks that have caused problems for the likes of British Airways, Zoom, and others. Successful hacks damage reputations, cause data loss and result in knock on effects for customers that are hard to recover from.

Software that isn’t well designed and built can also cause major problems for organisations, a recent example of this is the Post Office where the flawed logic of an IT system resulted in innocent people spending time in prison.

Less headline grabbing but equally important are software applications that are riddled with technical debt or become legacy due to a lack of maintenance. This type of software becomes hard to work with, expensive to maintain, and nearly impossible to adapt to support new requirements. This often results in expensive rewrites that could be avoided as the cheapest time to fix a bug is right after it has been identified.

Organisations often don’t appreciate how much costs spiral when people forget what the issue was in the first place or the code becomes unfamiliar.

Who is responsible?

Senior leadership in an organisation is ultimately responsible for the quality of a software solution. Leaders play a major factor in building the type of engineering culture that promotes quality and excellence in engineering and technical teams. By being aware of the pitfalls of poor quality, it is hoped that leaders will start to encourage quality and take a different perspective to the waterfall era of software development that was heavily focused on delivering to a timeline at the expense of robust quality and testing practices.

At a team level, another common misconception is that the Quality Assurance (QA) Lead or Tester will handle quality aspects of the solution, but this thinking results in a single point of failure and gives the wrong message to other members of the technical team.

For me, quality is a team responsibility and means writing clean code, setting and checking against coding standards, relying on automation and reducing manual effort, and ultimately building quality software that is performant and can evolve as new requirements emerge.

What can you do to achieve quality?

There’s no shortcut for experience. Experienced engineers will have already made or seen the big mistakes, and will keep you away from them. They will also drive quality across your organisation if they are given the space and support to do so from the senior leadership team.

In addition, there is also some practical guidance you can follow to ensure your code is of the highest quality and supports your business objectives:

• Code reviews are critical. These require time to do properly, as code is harder to read than write. Use linters and static analysis tools to make sure this time is spent usefully.
• Refactoring (small targeted rewrites of functionality to account for new understanding of what code is meant to do). This avoids the need for full rewrites later down the line.
• Testing is about proving a code does what it was meant to. Saving time by not writing tests is just assuming the codebase works, which is unrealistic. Testing also documents the expectations in the code, letting an engineer know that they have not broken an expectation when they make a change.
• Poor code quality often comes from rushed rewrites after a misunderstanding. This is avoided by good refinement practices, communication, and collaboration.

Summing up

The quality of a codebase is a concern that should be on the radar of the senior leadership team of any organisation, but particularly in larger enterprise organisations where software often exists for many years. In these cases, it should be continuously improved to avoid it becoming stale and transitioning to a ‘legacy’ state where risks become much more heightened.

Not taking code quality seriously can expose severe business risks and cause major issues from security flaws that lead to high profile hacks, reputational damage, expensive rewrites, project delays, and challenging maintainability. It often leads to user experience issues and dissatisfaction amongst both customers and internal staff, as poor quality codebases tend to be very hard to change and work with, and something that software engineers deplore working on.