Software quality means moving fast, for the long haul

There are many advocates of quick and dirty, with the dirty part being the necessary trade-off for an excellent time to market. In other words, never mind what comes next! Except that this dichotomy is misleading—and is all too often used to mask a simple lack of expertise: quality and speed are not mutually exclusive; quite the contrary.

Better yet: we’ll show that quality is, by its very nature, a temporal concept. To do this, let’s use a reductio ad absurdum argument.

Delivering quality in an infinite amount of time?

Suppose you have no automated tests. The behavior of the new feature will have to be tested manually; this is feasible, and in any case, it always needs to be done. However, you’ll also have to run regression tests manually after these changes.

Depending on the complexity of your application, this means testing hundreds or thousands of possible combinations. Except that here, unlike with unit tests, every slight variation from the previous test will force you to repeat the entire user flow. Feasible in theory, impossible in practice.

Thus, producing high-quality software only makes sense if it can be produced quickly, or at least reasonably quickly. Quality is therefore a concept deeply rooted in time.

It’s easy to produce quickly at the beginning

In the early stages of a product’s life cycle, it’s fairly easy to produce software quickly and without bugs. All the faster if you take every possible shortcut in the code, all the faster if you go into technical debt. To the untrained eye, this debt is invisible; the only thing visible is the software that works.

But the technical debt accumulated in this way eventually takes its toll, either in time, in bugs, or, more often than not, both:

• Bugs, because unintended couplings have crept into the code, because the code is hard to understand, and because there are no automated tests to “catch” them for you;

• In terms of time: in the best-case scenario, because developers are aware of the technical debt and perform refactoring before adding new features, while also increasing the number of regression tests. Otherwise, it’s just time wasted trying to stabilize an application that’s spiraling out of control.

A Definition of Software Quality That Incorporates the Temporal Dimension

At this point, the marathon metaphor should seem fairly intuitive: in development, just as in running, you need to adopt a pace you can sustain. Starting 1 km/h above your target pace jeopardizes your chances of finishing within your target time, or even of finishing at all. Developing at full speed, writing code that works now but without regard for architecture or testing, jeopardizes your chances of delivering complex features in the long run.

Since quality can only be assessed over the long term, we need to propose a new definition:

Quality is the ability to produce useful and usable software at a sustained pace over the long term.

In the end, it’s interesting to see that this definition of quality fully incorporates the concept of speed, even though many people like to pit them against each other.

In an upcoming article, I’ll use this definition to shed light on a difficult topic: how do we measure software quality?