Code quality is essential to keep us Agile; poor quality creates technical debt, the sum weight of which will slow us down. Working with low-quality code feels a little like moving through treacle; changes that we thought would be simple turn out to be much harder than we expected.

When considering measurements to help us ensure code quality is high, we should look to measures that help us identify and remove technical debt from our system.

A good analogy is to think of it a bit like weeding a garden. It's a constant chore that we need to keep doing, usually as part of other tasks, rather than a particular job that we do in its own right. Even if we're just walking through the garden on the way to somewhere else and see a weed, we pull it out. Taking the time to do this, little by little, will stop the weeds getting out of control before any of them become bushes.

So, what are the software qualities we should aim for to remain Agile? And how should we measure them?

The simplest way to measure them is first to set some standards for our team to follow. Record this somewhere visible and easily accessible to the team. The ideal space would be anywhere in a visible workspace alongside a Scrum Board.

Feedback on how we're progressing with quality standards is essential, and this can originate from many sources, such as peer review. We should set thresholds, so if one or more of our desired qualities drops too low, the team is warned to take action. There are some handy tools that monitor code quality automatically; examples include Code Climate and SonarQube.

These are some aspects of quality we should be monitoring:

• Clear: Clear code often comes down to the user's coding conventions. We should aim for consistency. A few examples include:
  • Keep function names short and meaningful.
  • Make good use of whitespace and indentation.
  • Keep lines of code to fewer than 80 characters.
  • Aim for a low number of lines of code per function—use functional decomposition, reduce conditional logic to the minimum, and so on.
• Simple: This is a two-parter:
  1. We apply the Agile principle Simplicity - the art of maximizing the work not done and only write code that we need now.
  2. We make refactoring part of our team's DNA. As Mark Twain once said, "I didn't have time to write a short letter, so I wrote a long one instead." He meant that to make something succinct and meaningful, we have to put in time and effort; this applies to our software too.
• Well-tested: A broad spectrum of tests which cover unit, integration and UI testing. We should aim for good code coverage and well-written, easily executed tests. If we want to maintain confidence over time, our test suite should be automated as much possible.
• Bug-free: Tests are only one part of the equation as they just demonstrate the absence of bugs, not their presence. To aim for a zero defect rate, we have to focus on clear and straightforward code because one of the biggest causes of bugs is code complexity. We'll take a look at this in more detail in the next section.
• Documented: We should provide just enough documentation so that those that follow behind us, including ourselves, can pick up the code and have a sound understanding of our original intent. To be frank, the best way to do this is through tests because they are "living" specifications of how our code works. Better still, we can write tests using Test-Driven Development (TDD), because this gives us specifications up front before we write code. We'll talk more about TDD in the next chapter. Besides tests, we should include code comments, README files, configuration files, and so on. 
• Extensible: Our software should be easy to build on and extend. Many will use a framework to give it some foundational structure. If we are using a framework to help guide extensibility, then we should adhere to the practices advocated by that framework as much as possible to ensure consistency.
• Performant: Performance is key to several qualities, including usability and scalability. We should have baseline measures such as response times, time to the first byte, and so on, which we can use to ensure our software remains useful.