Quality vs speed in software development: insights for CEOs

Making something of higher quality takes more time. We want to satisfy our customers at greater speed, so cutting quality is an opportunity to get something to them faster. If we use the example of tasks in our daily lives – such as getting things done from our daily to-do list – many choices have low consequences, so the idea appears to hold up.

The difference is that software development results from dozens of choices every developer makes every hour of every day. Let’s compare these to aspects of our daily lives – such as our health – which is a more complex interaction of our exercise, diet, whether we have an illness, environment and many other factors.

We can start to see the effects of choices on simple versus complex scenarios. In the simple case, the trade-off is clear and the consequences are immediate. The consequences of decisions are delayed for the more complicated example which depends on more elements. Poor decisions compound and we become unhealthy, overweight or out of shape.

How does maintaining product quality enhance the efficiency and speed of value delivery?

To understand why company culture is essential to consistently producing quality products, we must better understand how quality and delivery approaches relate.

Many people have an incomplete understanding of the relationship between quality and speed of delivery. Speed and quality are often framed as trade-offs against each other. This may have been influenced by project management concepts such as The Iron Triangle. This may be true over a short period, but the dynamic between these two dimensions is more nuanced when delivering quality over the longer term.

When there are choices to compromise quality for expediency, there is often either a commitment to come back and address the quality or a growing set of quality issues that detract from the experience of using the product. Cutting corners for expediency generally leaves work to be done at a future date and perpetually cutting corners can accrue a long list of things to do to bring the experience of using the product up to an expected level for the users to continue to enjoy and value using it.

On the other hand, trading off quality to deliver something for the benefit of learning may be worthwhile if it prevents us from over-investing in things we haven’t yet validated to meet customers’ needs.

An under-appreciated reality of many quality issues is that they contribute to delays. Documenting and managing issues comes with an overhead, and the more prolonged unaddressed problems are managed in a bug database, the more time is devoted to managing them, prioritising them and moving them between projects and other non-value-adding busy work. Deciding to avoid addressing the issue this week to speed up over the short term often reduces the long-term average pace.

Unaddressed bugs can also directly cause delays. For example, a bug might result in navigating a part of the application more slowly, which impacts developers and testers, but not customers. It’s not uncommon to see development teams wishing they could prioritise issues that slow them down daily, but struggle to justify prioritising this effort due to a well-meaning desire for expediency over the short term by those with the authority to make such prioritisation calls. These patterns repeat and there’s never time to improve their pace.

Another facet to consider is that quality is experienced across many dimensions. Users appreciate many aspects of software, such as:

• The software’s performance, such as how quickly the page renders, how long it takes to load reports or other types of results and the latency and responsiveness of controls
• The interoperability of the software, such as its ability to integrate with and work with other software
• The software's safety – such as its security, trust and safety standards – will help prevent users from being defrauded or from other events that may cost them financially, reputationally or even their personal safety
• Is the software easy to maintain? Such internal qualities may translate for users in terms of the rate at which new capabilities in the product become available

It’s often unrealistic to address every qualitative dimension within a fixed period for any given product iteration. The qualities you focus on should be influenced by the stage of the product lifecycle your particular product is in. For instance, it may be premature to invest in achieving compliance with specific industry security standards before validating some degree of product market fit. There are choices every team makes about where to focus. The fidelity required depends on where you are in the product lifecycle.

Equally, it would be unwise not to invest at all – for instance, not investing in fundamental security practices as you progress, especially when the software becomes more publicly accessible. A security compromise could be an existential threat to a young company’s reputation.

As you can see from these examples, the choices to prioritise particular investments require a thorough understanding of the context of the stage the organisation and its products or services are at and the application of judgment all along the way to make the best possible decisions about how much to invest and to what degree of quality. There’s not a black-and-white, always-relevant answer that can apply to all situations.

For these reasons, there is not a single set of ‘best practices’ that will guarantee a certain level of quality in software. This is especially true in software that solves new user problems and provides new solutions. The predictability of software delivery improves depending on how well-known the users’ needs and problems are and the degree of the solutions’ commodification. The challenge is that situations and contexts can differ subtly due to the many components interacting across the software, the user and their environment. The effects this has on the experience of using the software can be profound, undermining how well we truly understand the context for users and predict the efficacy of the software we deliver in addressing their needs.

Why is delivery pace critical to sustaining long-term value creation?

The pace at which teams deliver – and by ‘pace’, I’m referring here more to the frequency and consistent heartbeat of delivery than the speed – is a crucial aspect of what contributes to a valuable, successful product in the long term. This is because of the opportunities for feedback, which allow the team to course-correct.

Feedback is an essential complement to good skills and practices. While competency and using the most appropriate practices can increase the likelihood of quality, more is needed. The range of scenarios and situations is too numerous and the number of elements interacting is too complex to predict the exact suitable approaches to deliver good quality reliably. There is a need for regular points of inspection and retrospection to check what we are doing that is providing the desired result and where we need to improve.

Feedback loops in software development can often be likened to Russian dolls – different feedback cycles with varying periods, each nestled within the other. The use of intelligent, integrated development environments provides engineers with feedback literally as they type. The advent of DevOps and automation has enabled feedback loops to occur with each build or other key events, such as deploying to different environments like development, staging and production.

Some cycles might be more frequent and others less frequent. Still, they all benefit from some regularity to pay-as-you-go instead of accruing some effort, which may need to be addressed later and from providing different types of feedback at the right times for the team to respond and make the necessary adjustments to keep improving the product quality to meet the customers’ expectations.

What are examples of the different types of feedback loops present in software development?

Different aspects of software quality may need different feedback cadences to work practically. By ‘cadence’, I mean regular cycles of review and validation. For some aspects of quality, it will be with each change and the more atomic and self-contained the changes, the more frequent the feedback loop can be.

Higher-level concerns, such as how well the functionality addresses users’ problems, might be less frequent, although in general, more frequent is better, as is practical. Companies often need to pay more attention to the full degree of opportunities to engage with users for feedback because there may be some initial friction. The most committed organisations focused on understanding the user experience of their products had groups of users coming to their offices for user research sessions every week. How often are you researching to understand your customers’ needs and validating that your solutions meet those needs? How many assumptions are your solutions operating on?

Even higher-level concerns, such as strategic cohesion, for instance, how well what has been developed and delivered to customers is addressing strategic goals, might be conducted over lesser frequency due to the time changes that may manifest. It’s common for the review of strategy and alignment to be done quarterly or at a similar frequency. Doing it at a lesser frequency could lead to more investment misaligned with the organisational goals or strategy for longer, leading to significant wasted effort of scarce resources.

The shorter the feedback period, the less variation between how the software functions and what is needed. Of course, this is only true if the team is in a position to address any deviations detected. This may seem self-evident, but again, it occurs in companies quite often for software development teams to be placed in a situation where they do not feel empowered to address issues identified, even when they know the impact these will have on the quality of the resulting software and the degree to which the cost to address these later will increase.

One example of this is when using project management practices with software development. The false security of project planning can create situations where teams have effective feedback loops for detecting variation but ineffective mechanisms for addressing these issues. The cost of addressing these issues increases as the time between identifying and rectifying the problem. Decisions of scope within traditional project management approaches can give the impression that the amount of work is constrained. Still, a growing quality problem has been introduced and the cost of rectifying this is growing and marked as the responsibility of a future project to fix.

How does development flow impact software quality?

The focus on improving flow is on improving the frequency of feedback loops. The frequency of feedback loops, in turn, is directly correlated to the quality of the software and how well it addresses the users’ needs and expectations.

How organisations evolve and how the people working there are organised is not always conducive to a smooth flow of software development work. This is rarely the top consideration when deciding choices for arranging team structures. The work to get any one thing done may be spread out over many people across many teams, which adds many points in time when work is waiting on another party within the organisation to be available to complete the next step.

The result is that there is less and less opportunity for feedback loops essential to testing and validating the quality of the software to occur. A company that can test and deploy software once a month may only have 12 good opportunities to course-correct its software. This is the equivalent of being limited to only using the big chisel when creating a sculpture. With the sophistication of modern software and the rising expectations of consumers and business users, this is a recipe for significant limitations regarding what quality is possible.

Flow optimisation is concerned with reducing these wait times by reducing the waiting time between each step. This may involve bringing the right people together and empowering people with the authority to make decisions, rather than waiting for others to make decisions.

How do team empowerment and ongoing feedback accelerate customer value delivery?

A culture conducive to continuous improvement is needed to maintain an environment where feedback flourishes and there is a constant development flow – continual work free of unnecessary pauses and delays.

The team members actively creating the software are best able to understand the choices that affect the software development flow and the effectiveness of feedback mechanisms. Every choice can either enhance or inhibit the flow of value and thus hasten or delay the flow of feedback. This is why empowering decision-making at the team level is critical for supporting software quality.

Whether teams are empowered has a lot to do with the organisational culture. As CEO, you might even have stated a desire for empowered teams, but then puzzle over why you observe examples of this empowerment being undermined. It’s not enough to decree empowerment. The environment and the culture must be cultivated to nurture and support the agency of teams to make material choices about how they work and take responsibility for the quality of products they produce.

The faster teams can hone software to an adequate level of quality such that users can try the software – further validation can be realised as users confirm or demonstrate they cannot use the software to address their needs. The faster they can refine the software to meet their needs and expectations, the better. Higher frequency feedback loops within the development process can support faster loops in the design and user validation feedback loops. Long delays in getting software into production are one example of a preventable delay typical in larger companies and delays in critical feedback, which can help identify whether teams are building the right thing. Investments made while waiting for this feedback are more likely to be wasteful – to spend good money after bad.

This situation can compound poor quality or product fit regarding how user needs are addressed, often met with knee jerk responses. More features are added to compensate for falling interest from users frustrated with issues of quality or relevance to the problems they are trying to solve, causing quality and fit to suffer further.

Contrast this to the alternatives that good use of feedback loops offers. In an age where software can be delivered through the cloud and instantly used by its intended audience, this affords a virtuous cycle of software development. Through a combination of regular learning through user testing, instrumentation of the users’ product usage and the feedback available through their build automation that detects bugs, security risks and other issues that can be paid off as the team goes, the confidence that the product is relevant and meets the quality thresholds can remain high throughout the development lifecycle.

What is the advantage of continuously improving consistent, high-quality products?

Supporting an environment where software constantly improves and maintains high quality throughout its lifecycle unlocks several key benefits. First, the software is more often in a state where it can be used by real users who can validate or invalidate our assumptions about whether it meets their needs. Secondly, the pace at which the teams can operate is more consistent as they are not impeded by a rising number of quality issues that must be addressed.

In a future post, we will explore how CEOs armed with this knowledge about how quality and speed actually relate in software development and the importance of supporting multiple layers of feedback loops can inform how CEOs can best support successful software product development within their organisations.

If this blog has prompted you to wonder if these dynamics were at play within your organisation and you’d like some help investigating, please get in touch.