Do Not Treat Quality as a Separate Activity

If there is only one thing to know about software quality, it is this: do not separate your efforts into shipping features and improving quality.

Code that is resilient to future changes has certain properties:

  • it is easy to understand
  • it has effective test coverage
  • its interfaces have been intentionally designed to deal with expected future changes well

If you aspire to write low-quality code, wait to do these activities until after you have deployed the code to production:

  • simplify or document the code
  • add tests
  • clean up the messy implementation
  • get the code reviewed by a peer

Think in Terms of Causes and Effects

Let’s take a moment to examine the forces that are at play in a software project and you’ll see why having separate quality activities is a bad idea:

  • there is always pressure from business stakeholders to ship features sooner rather than later
  • time spent on quality activities is a hard sell to business stakeholders because it’s a guaranteed cost right now for a possible, hard-to-measure future benefit

Separating out quality as a distinct set of activities has the very unfortunate effect of creating an unnecessary conflict. Instead of negotiating scope and schedule with business stakeholders, you are now negotiating engineering practices. Software quality, which by definition should make it easier to ship code, could even begin to appear like a distraction to shipping code.

Do Not Deliver Incomplete Work

Cut scope, not quality.

Cut scope, not quality.

Deadlines are real and time runs out. If you treat quality as a separate activity, your workflow looks like this:

  • write code that implements the desired product feature
  • clean up, refactor, test, and document the code

Which means that when time runs out, quality runs out.

Each unit of work that is delivered should be complete and whole, meaning it not only implements the currently requested feature, but also honors the non-functional requirements of the system and meets software quality standards. You do this by weaving these indirect concerns directly into the process of building software. Test-driven development is a great example of this. Because writing code and writing tests are the same activity, it’s impossible to get into a state of shipping code without appropriate test coverage.

Wyatt’s Rules of Software Quality

I hope this blog post has given you something good to think about! If you wish to read more, this post is part of a four-part series on software quality:

  1. Define quality
  2. Manage causes, not effects
  3. Do not treat quality as a separate activity
  4. Apply standards consistently
You can skip to the end and leave a response. Pinging is currently not allowed.

Leave a Reply