This article was written for, and originally published by TechBeacon as ‘How to deliver speed without losing your customers’. You can find that original article here.

---

The complex relationship between velocity and quality

There is a widespread narrative that in software development and deployment, faster is better.

The inexorable move among teams and organisations towards methods associated with Agile principles has been followed by the rise of DevOps practices. For businesses, a desire to make changes to software more quickly, and to get these changes to customers at shorter intervals, has been one of the primary motivators in adopting these method and practices.

Organisations that have succeeded in implementing mechanisms which allow them to deploy code changes frequently and rapidly are held up as examples of how things could (and perhaps should) be done. The likes of Facebook, Netflix and Amazon are able to deploy code changes multiple times each day, and other organisations aspire to the kind of models that allow these companies to do so.

Whilst there is far more to DevOps culture and practices than rapid, frequent deployment, some of the most eye catching claims and statistics that have emerged about these organisations’ software practices over recent years relate to speed and frequency, notably Amazon’s famous 2011 revelation that they could deploy to Production every 11.6 seconds. Yet, leading proponents of DevOps have also emphasised the importance of quality, and with good reason as there are undoubtedly challenges associated with making change at pace.

Whether you believe these quality challenges are given appropriate attention probably depends a great deal on what you understand quality to mean.

If you believe that it is the development and distribution mechanisms – the processes, methods and tools involved in creating, deploying, and maintaining software – that really matter; that if we optimise these, then we will naturally deliver on quality, then you may well be convinced that many of the challenges have indeed been addressed. After all, much discussion and debate has contributed to the refinement of practices, and there are undoubtedly some clever and reliable tools which allow some of the tasks involved to be automated and the systems themselves to be monitored.

If however, you believe that quality can only be truly assessed through the perception of the human beings that the software is intended to serve, that the relationship between person and product is what really matters, then there are some factors in this relationship which might be worthy of greater consideration.

Business need and the benefits of speed

Firstly, lets look at some of the reasons why, for some businesses, speed of delivery can itself be considered an important factor in quality. There can be compelling business reasons for adopting mechanisms that facilitate rapid deployment, and they can bring great benefits to customers too:

• Changes allow companies to demonstrate a willingness to listen and rapidly respond to customer feedback which can be elicited through direct contact with customers (e.g. from surveys and product reviews), or through means which are less apparent (e.g. telemetry). If direct and indirect feedback from customers is properly analysed and considered, and if objective decisions are made about which changes which will provide a better experience, then there are clear benefits for both businesses and the people they intend to serve.
• In dynamic markets, being the ‘first mover’ – the first company to get to market with a product or feature – can provide a competitive advantage, and for software applications a quick and reliable deployment mechanism facilitates this. Such mechanisms can also enable ‘fast followers’ – those companies who move quickly into the market with a similar product or feature – to respond if a competitor gets there first.
• For the customers who use products, mechanisms for rapid and frequent change mean that problems can potentially be resolved quickly. The mechanisms also offer opportunities to be the first to try new features or own new products. Novelty can be a quality aspect for some. Why do people line up outside Apple stores for hours (or even days) in order to be the first to use a new iPhone model? Because they want to be the first to experience the new features provided, and probably want to be able to tell their friends about it. To them, novelty matters.

The potential benefits of rapid, frequent change to businesses and their customers seem clear, but there are other considerations which are less commonly discussed but which should not be ignored.

When is a product not a product?

Fundamentally, frequent change dramatically alters the notion of a ‘product’. In many instances, the software we purchase is not the same product that we use after a week, a month or a year. Whilst many of the code changes made to software may be hidden from the person using the product (perhaps to improve performance, stability or security), over time there are likely to be some visible changes too; features may be added, altered or removed, and methods of operation, the look and ‘feel’ might also alter.

Video games are a good example of this changing landscape. A decade or more ago, a gamer may have visited a store, decided which game to purchase, and returned home with a disc to use with a games console. The game itself might offer different modes of play and configuration options, but these would be limited to whatever was contained on the disc. The product, no matter how complex or rich in features it might be, did not change.

Digital distribution has fundamentally altered the relationship. A gamer might now download an initial version of a game but this core game is likely to be altered through updates over time. New game modes might be added, additional characters made available, menu structures changed and so on. Patches and upgrades are required. The product changes. It could be argued that it has now taken on the characteristics of a service.

So what does all of this mean for quality?

Despite the benefits, there are effects associated with frequent change which might not be desirable to some of the people who use software products. Here are some examples:

Familiarity

Some people may simply prefer that products retain the characteristics and features which existed when they made the decision to purchase them, or when they first used them. This might not be a concern to people (including those of us who work in software development) who are comfortable with technology, but what about people who perhaps take time to familiarise themselves with the appearance and operation of software? If they use the software in question to carry out important tasks – for example using a banking app to pay rent, or an energy company website to pay a bill which allows them to keep their home warm – readjusting to changes might be confusing or worrying.

How might changes which visually alter a screen, and are straightforward for fully sighted people to adapt to, affect somebody who is visually impaired? Small changes could confuse but significant changes here could be bewildering.

It is not the case that everybody values change and novelty. For some, familiarity might be crucial to their perception of quality.

Availability

Means of downloading and installing patches or upgrades can also affect perception of a product. Delays, preventing us from using software until a new version of a product is installed, or a device is restarted, can be great sources of irritation, particularly when there is an urgent need to use software. The person running late for an important video call for example, will not welcome a lengthy upgrade to the software.

Meanwhile, downloading large update files can be problematic for those with limited mobile data allowances, or limited bandwidth available on a home network. Such updates can take time, limit access to network features and cause frustration for others too. Preventing family members from streaming their favourite show in the evening is not likely to generate goodwill.

Frequently updating your product counts for little if people are frequently prevented from using it.

Assistance

A person’s experience with a product can depend on far more than the code which drives its operation. Support and communication can be crucial elements, particularly when introducing something new or changing the way something works after a long period of consistent behaviour. The help offered within a product may require adjustment, staff may need to be trained, and communications to customers about changes may also be required. If changes or new features are not matched with accurate and reliable support mechanisms, confusion and frustration is likely to result.

Meanwhile, there are important accessibility considerations associated with changes, for example screen reader compatibility, alternative text and accessible form controls which could make those changes, and perhaps critical features, unusable for people who rely on your product.

The balancing act

Some basic principles can help balance the pace of delivery with these risks to quality:

Size over speed

A focus on incremental change (rather than rapid change) with smaller, more targeted adjustments typically carries less risk. Specifically:

• changes in operation, look and feel are likely to be less noticeable and therefore can be more easily accommodated by people who value familiarity
• upgrade file sizes will be reduced, installation times shorter and therefore the process less disruptive
• simple instructions can be used to communicate the nature of the change in a consumable and learnable way.

A byproduct of this may be that changes can be made more rapidly and more frequently, but the emphasis on size rather than speed is a healthy one for quality overall.

Speed is nothing without control

in this case, the control that matters is the control that the people who use an application have over the changes that are made, and when they are made. A feeling of control can result from:

• providing opportunities for people to react to features and other changes they like or don’t like
• simple configuration options to toggle changes on and off where possible, or in some cases retaining existing behaviour or appearance with an option to switch changes on (rather than the other way round)
• choice over when to install an upgrade, and clear information on the implications (e.g. the file size, likely duration of an installation, need for restarts)

Focus on the human factor

Think about the people using your product, then really think about the people using your product and their needs. Empathy for your customers, colleagues or anyone else using your product can go a long way in providing them with a rewarding experience. For example:

• consider Accessibility for every change you make and factor in regular checks for potential Accessibility problems
• offer simple and understandable opportunities to learn about changes and how to enable or disable them
• keep all support channels – e.g. documentation, support staff, forums and communities – well informed about what has changed but also why it has changed
• if you are not able to offer choice or control (e.g. an urgent security patch is required), communicate why this is the case

Recognising the great advantages that speed of delivery can bring does not mean that there isn’t time for considering some of the risks to quality that may come with the territory, and it certainly doesn’t mean losing sight of the people software is intended to help. As we adjust our products, taking time to think about the different needs and desires that those people might have can help remind us that it is their product too. After all, what is the advantage in delivering at speed if we don’t meet people’s needs?