I recently came across a YouTube video in which host, Dave Farley, made a bold assertion: “There’s no trade-off between working quickly and working with high quality.” [1, 0:47] Is this statement true?

The Speed-Quality Relationship

At some point in your life, you likely experienced what psychologists refer to as, the speed-accuracy trade-off. That is:

• The faster you strive to complete a task, the less accurate you’ll be, and
• The more you strive for accuracy, the slower you’ll complete the task.

There’s an inverse relationship between speed and accuracy. We’ve all experienced the speed-accuracy trade-off first-hand. We know it’s real. So, given that “accuracy” and “quality” are interchangeable in this context, what’s Dave Farley talking about?

It’s easy to interpret his assertion to imply that he debunked the speed-accuracy trade-off, in general. He didn’t. His statement makes more sense if rephrased like so:

Statement #1: There are situations in which accuracy cannot be traded off for speed; therefore, in those situations, there is no speed-accuracy trade-off.

This implies:

Statement #2: Where a relationship exists between speed and accuracy, but there is no speed-accuracy trade-off, speed and accuracy must increase or decrease, together.

This makes sense mathematically, but it may help to see how it all comes together using software development as an example since that’s what Farley’s talking about.

Speed-Quality in Software Development

First, let’s consider a software developer’s duties. In a more ideal world, a developer’s duties can be divided as follows:

• Primary duties may include creating new features and enhancing existing features.
• Secondary duties may include fixing bugs, reworking features, and paying off technical debt, in general.

Ideally, developers should only spend time developing new features or enhancing existing ones. For this reason, overall (long-term) development speed is only measured against primary duties. Development speed is maximal in a world in which developers devote 100% of time on new features or enhancements. From this point of view:

• Secondary duties arise from imperfections that impede primary duties.
• Time is limited, so time spent on secondary duties is time taken away from primary duties.
• Less time available for primary duties means lower overall development speed attainable for them.
• So, minimizing time spent on secondary duties grants more time and speed available for primary duties.

With this in mind, let’s revisit Statement #1. In software development, quality cannot be sacrificed for speed gains. When quality decreases, speed decreases too. There’s a direct relationship between the two. But hold on…psychology experiments show that accuracy can be sacrificed for speed gains. How can this be?

Experiments that demonstrate the speed-accuracy trade-off focus on the relationship between speed and accuracy, on their own. They don’t explore second order effects. But actions have consequences, and those consequences bear their own consequences. For instance, what happens when degraded quality changes the way a person performs a task? How does the change in behaviour affect speed?

In software development, quality may be unintentionally degraded due to human error (e.g., a bug), or intentionally degraded when cutting corners to meet deadlines (e.g., a workaround). There are other causes of quality degradation, but we’ll focus on the “intentional” type because when people talk about speed-quality trade-offs, they usually mean sacrificing quality now by cutting corners to meet a deadline and making up for it later.

Unfortunately, cutting a corner adds work. Temporary code must be written to present the illusion of satisfying deadline requirements. This code must be replaced at some point in the future with proper code. In the meantime, other features may be developed around and on top of this temporary fixture. These are workarounds that are inherently inefficient. When it’s time to replace the cut corner with the actual feature, everything dependent on the temporary code must be reconstructed into a cohesive piece of the application. None of this would have been required if the code were written correctly in the first place. All this extra work takes extra time. They’re mostly secondary duties because the actual feature implementation will replace most (or all) of the temporary content.

Cutting a corner is an example of sacrificing quality. More work is created in the process but does not pertain to creating a new feature or enhancing an existing one. In other words, sacrificing quality in software development always delays the development process; thereby, reducing speed.

All of this coincides with the debt metaphor; hence, the term, technical debt. When you cut corners, you incur technical debt. The debt must be paid off in the future when it will be bigger. In the meantime, the debt accrues interest. In other words, every time technical debt is incurred, quality decreases. The debt must be paid back in full plus interest to restore quality. The cost of interest, and payback, is speed. Ergo, when quality declines, speed declines.

This practice is driven by the misconception of the speed-accuracy trade-off — that quality can be sacrificed to gain speed to satisfy a deadline.

It’s an illusion of short-term thinking concealed by the deadline, itself.

When focused solely on a short timeframe from “now” until the next deadline, everything beyond the next deadline is ignored. A person can fool themselves into believing that corners can be cut to gain speed by pushing corrective efforts (e.g., bug fixes, rework, etc.) “out-of-scope” into the next development iteration. “If we don’t have to bear the consequences of reduced software quality in this iteration, then we’re trading quality for speed, right?” Nope. Developers must still work with less efficient, stopgap measures. More importantly, speed is reduced in the long run because, eventually, bugs must be fixed, and features must be built properly for the application to function well in its entirety.

In other words, any attempt to speed up by cutting corners only results in overall speed reduction. Speed is reduced because of software quality issues that the developer must address, drawing effort away from new features and enhancements. This is true on all levels. When the quality of a software feature degrades, so does the speed of its development.

Indeed, there is no speed-quality trade-off in software development. When you choose to sacrifice quality in software development, you are also sacrificing speed.

Try It Yourself

In addition to these examples, this walkthrough, Dave Farley’s explanation, and the findings of the State of DevOps report, you can also observe these speed-accuracy phenomena empirically. Try conducting your own scientific experiment by going to a website that tests typing speed and accuracy. Then, perform a typing test for each of the following scenarios, and record your results:

• Focus on accuracy and correct every error along the way.
• Focus on speed and correct every error along the way.
• Focus on accuracy and don’t correct any errors.
• Focus on speed and don’t correct any errors.

Try this set of scenarios multiple times, mixing the order, but ensure that each test setup is the same. Then, aggregate the results.

Obviously, this isn’t meant to be rigorous, but a proof-of-concept. There are also limitations to this experimental setup because an error doesn’t incur penalties for the duration of its existence. The only speed penalty is going back to correct a typo. In software development, however, the mere task of having to work with garbage code incurs speed penalties. For example, if you’re coding and you encounter a bug that’s in the process of being fixed by another team member, you’ll need to work around it. You’ll need to coordinate your changes with whatever solution the other developer is implementing, all of which takes time, and reduces your overall development speed. Then, there’s the rework afterwards.

Conclusions

1. The speed-accuracy trade-off phenomenon exists.

2. There are situations in which inaccuracy alters the performer’s behaviour such that speed is adversely affected. For example, needing to go back and correct most or all errors.

3. Inaccuracy’s second order effects on speed can be so significant that the inverse relationship between speed and accuracy inverts into a direct relationship; accuracy and speed increase/decrease together; accuracy can no longer be traded for speed, and vice versa.

4. Software development presents an example context in which there is a direct relationship between speed and quality. So, there’s no trade-off between them.

5. All attempts to cut corners reduces quality and incurs technical debt; thus, speed penalties. All attempts at quality trade-offs result in speed penalties. In other words, as quality decreases, speed decreases.

6. Quality drives speed.

7. Quality must take precedence to maximize software development speed over the long haul.

References

[1] Continuous Delivery, How To Build Quality Software Fast. YouTube. Uploaded: June 2nd, 2021. Available: https://www.youtube.com/watch?v=ZmgbjaRfp_Q. Accessed: June 3rd, 2021.