Quality vs Speed in software development: Reframing the debate

In any software project there’s inevitably a discussion about how to approach development speed vs quality. Many in fact. It is one that I have struggled to clarify at times. But, I’ve now realized that framing it as either/or is the wrong way to think about it.

Understanding quality in software

In software, quality can refer to many things. It can describe the visual design and the user experience. It can describe how performant things feel. It can also describe how the code is structured, the boundaries and interfaces. How things are named. How well we can verify functionality. Broadly, there are three categories:

• Functional quality: the visual design and how well the software meets the needs of the user.
• Non-functional quality: performance and security
• Technical quality:

The hidden importance of technical quality

In the early phases of a product, it is important to deliver value to users quickly. Only by putting product in front of users—can you really start to understand if you are building the right thing. This emphasis on delivering quickly, whilst important, is often used as a reason to cut corners. And when quality is on the chopping block, it tends to be the technical that is cast aside.

It is just easier to justify spending time improving the UI, or making things faster. These are things that are visible to users. This can become a problem come if you continue to prioritize speed over quality, repeatedly, over time.

For anyone who has worked in a software project that has been around for more than a few years this is evident. The multi-month rewrites. The huge swaths of ‘legacy’ code. These all come from neglect.

The trade-off is not between speed and quality. It is between speed now and speed later. What makes the trade-off difficult to balance is that, for a short while, you can keep leaning towards speed with little impact. And, because we do not have good ways to measure this, it’s not obvious at what point the balance tips in favor of quality. By the time you realize that you need to invest more in quality, it’s often too late.

This shows up as feature-by-feature, the software becomes more difficult to change. Estimates become longer and longer, and more customer-facing bugs slip into releases.

Technical quality makes it easier to change

Software is not like building in the physical world—despite being a well-used analogy. Software is always changing. Requirements even change whilst building. When engineers add features, they need to build on top of existing features. This requires understanding the existing code. Understanding what needs changing and then being able to make changes confidently. How easy the existing code is to understand affects how quickly features are built.

This is why the technical quality is so important. Because technical quality makes a system easy to maintain, and change.

Speed and Quality

To move quickly you need quality. But not all aspects of quality are important. We need to focus on the aspects that make things easy to change.

Velocity does not equal haste. It is possible to deliver high quality work at high velocity. The way to do that is to have a maniacal focus on the fastest path to value Henry Ward

Balancing speed and quality

well-thought out interfaces can allow you to remove or replace whole components without following tendrils into all corners of the codebase; good test coverage can make you more confident when making changes, can reduce the number of bugs, and helps to minimize time in QA” — Dan Pupuis

Spending time on the architecture, defining the boundaries between components is not a cost but something that makes future changes easier. Which speeds us up over time.

And users do see this: they get more features over time. They get better reliability.

Conclusion

Next time you enter a discussion on speed vs quality consider what the true trade-off is. Understand what aspects of quality you may not need yet. Don’t compromise on the technical quality and maintain your speed well into the future.