Should software engineering teams prioritise speed over quality?

Like many other things in software engineering, it depends!

TL;DR: Moving faster could allow your team to test more assumptions, shorten the feedback loop or launch a new feature to the market ahead of your competitors, which could be a crucial advantage in the short term. On the other hand, it would also mean you are sacrificing resilience, longer term scalability and are creating technical debt which your organisation will inevitably have to pay later, meaning it would never work as a long term strategy. As long as the choice is deliberate and the trade-offs are carefully weighed, you can focus on speed for a limited time and then pay the technical debt you have incurred while doing so.

The debate is more nuanced than that though. The right balance between quality and speed depends on multiple factors, a few of which I will discuss below.

How mature the company/product is

In a pre product-market fit startup where the name of the game is exploration and validating assumptions, it makes perfect sense to keep the codebase as flexible as possible and prioritise speed over quality. What is there today might not even exist tomorrow as the company pivots onto a different path. Abandoning or re-building substantial parts of the codebase is very common in these early stages of a company, so spending extra engineering effort to ensure high levels of stability and resilience is simply not worth it. In this phase, the balance should be tipped towards speed, while keeping quality at a “just good enough to be used prototype” level.

However, once the product is relatively well defined and the company is growing/mature, the probability of radically pivoting drops significantly. At this stage, short term development velocity will need to take the back seat in favour of improved long term quality - which believe it or not, will also translate into better long term velocity. The right practices and processes need to be in place to reduce the possibility of defects reaching production, the right monitoring and alerting for detecting the ones that do must be implemented, your pipeline must include stages like static code analysis, vulnerability scanning, performance testing, end to end testing, smoke testing, engineers should practice Test Driven Development an so on.

Generally speaking, the balance should be even between speed and quality for more mature companies - although in real life it will keep shifting depending on the company or team’s priorities, which brings us to the next factor.

Priorities

We've all been there, sometimes the benefits of moving faster in the short term outweigh the drawbacks. If launching an MVP for a new feature ahead of your competitors could provide your company with a significant market advantage, it might be worth temporarily prioritising speed over quality. In such scenarios, the potential for capturing market share or establishing a first-mover advantage could justify a calculated risk in accelerating development timelines.

But, prioritising speed at the expense of quality for more than a short period of time will inevitably lead to reduced velocity, frequent failures, brittle code, increased team cognitive load and even burnout, making it an unviable long term strategy.

As the company or team’s priorities shift, so will the speed/quality balance, and that’s ok as long as the tradeoffs made are intentional and well understood.

Risk tolerance

The increased risk that comes packaged with prioritising speed over quality might be more or less acceptable depending on the industry the product serves and the potential consequences of failure. This risk tolerance varies significantly across different sectors, influencing the balance between speed and quality in product development. For example, sacrificing quality even for a very short period of time would be completely unacceptable in areas where human lives could be at risk, such as aeronautical engineering, automotive manufacturing, or medical device development. In these high-stakes industries, maintaining rigorous quality standards is paramount, as even minor errors or oversights could lead to catastrophic outcomes.

On the opposite end of the spectrum, we find low-risk industries where the consequences of potential failures are less severe. In sectors like gaming, entertainment, or certain types of consumer software, there might be more flexibility to prioritise speed over quality in certain situations. This is not to say that quality is unimportant in these fields, but rather that the trade-offs between speed and quality might be evaluated differently.

However, it's crucial to note that even in these lower-risk sectors, consistently prioritising speed over quality can lead to the negative consequences we have already described above. Therefore, the decision to favour speed should always be strategic and time-bound, with a clear plan to address any accumulated technical debt or quality issues in subsequent development cycles.

Conclusion

The factors discussed above are, in my experience, the most important considerations guiding decisions around the speed/quality balance in software development. However, it's important to note that this list is not exhaustive. The software development world is diverse and ever-evolving, and there may be additional factors that come into play depending on the specific context of your project or organisation.

The key takeaway here is that prioritising speed over quality for a brief period can yield excellent results. However, it's crucial to avoid the pitfall of neglecting to rebalance priorities and address the accumulated technical debt one the velocity push you needed is over.