Despite the widespread belief that faster is always better when it comes to software development and deployment, that's not always true. In your quest for speed, you may end up alienating some of your customers.
The move to agile, and then DevOps, has been mostly about producing more software more quickly. Some of the most eye-catching claims and statistics that have emerged about these practices relate to speed and frequency, notably Amazon's famous 2011 revelation that it could deploy to production every 11.6 seconds.
But there's more to DevOps culture and practices than rapid, frequent deployment. Leading proponents of DevOps have also emphasized the importance of quality.
You may believe that by optimizing the processes, methods, and tools involved in creating, deploying, and maintaining software, you will naturally deliver on quality. But if technology rules the relationship, that won't necessarily happen. Quality can only be truly measured by the people who use the software; the relationship between customer and product is what really matters.
Consider some of the reasons why delivery speed is an important factor in quality for some businesses. There can be compelling business reasons for adopting rapid deployment, and they can bring great benefits to customers, too. Here are just a few.
The business benefits of going faster
Businesses can demonstrate willingness to listen, and rapidly response to customer feedback.
You can elicit this feedback through direct contact with customers (including surveys and product reviews), or through less apparent means, such as telemetry. If companies properly analyze and consider direct and indirect feedback from customers, and if leadership makes objective decisions about which changes will provide a better experience, then they will see clear benefits for both the business and the customers they serve.
In dynamic markets, being the first mover can provide a competitive advantage.
A quick and reliable deployment mechanism facilitates this for software applications. Such mechanisms can also help fast followers—companies that move quickly into the market with a similar product or feature—respond if a competitor gets there first.
Rapid and frequent change mean problems can be resolved quickly—a plus for customers.
The mechanisms also offer opportunities to be among the first to experience new features or own new products and tell friends about them. To some, novelty matters.
The potential benefits of rapid, frequent change to the businesses and its customers seem clear, but here are a few other considerations you shouldn't ignore.
When is a product not a product?
Fundamentally, frequent change dramatically alters the notion of what constitutes a "product." In many cases, the software that customers purchase is not the same product they use a week, a month, or a year later. While many of the code changes in software may be hidden from the customer (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 the look and feel might also change.
Video games provide a good example of this changing landscape. A decade ago, a gamer may have visited a store, decided which game to purchase, and returned home with a disc to use with a gaming console. The game itself might have offered different modes of play and configuration options, but these options would have been limited by whatever was included on the disc. The product 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 change 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.
What does this mean for quality?
Despite the benefits, the people who use your software may not always welcome frequent change. Here are some examples of how rapid change can create a negative experience for your customer.
Your app has morphed into something less familiar.
Some people may prefer that products retain the characteristics and features that existed when they made the decision to purchase them, or when they first used them. This might not be a universal concern, especially among those comfortable with technology, but some people need time to familiarize themselves with the appearance and operation of software.
If they use the software to carry out important tasks—for example, using a banking app to pay rent or an energy company's website to pay a bill that allows them to keep their home warm—adjusting to changes might cause confusion and worry.
Also, consider how changes may affect those with disabilities. A seemingly straightforward screen change that's obvious to a sighted person might make the app unusable to a visually impaired person. Key accessibility considerations include screen reader compatibility, alternative text, and accessible form controls.
Not everyone values change and novelty. For some, familiarity might be important in their perception of quality.
Your constant updates annoy customers.
Constant downloading and installing of patches or upgrades can also affect users' perceptions of your product. Delays that prevent customers from using software until a new version is installed or the device restarts can be a great source of irritation, particularly when they have an urgent need to run the software. A person running late for an important video call, for example, will not welcome a required lengthy upgrade to the software.
Meanwhile, downloading large update files can be problematic for those with limited mobile data allowances, or those who have 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 favorite 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.
Your training and support aren't keeping up with product changes.
A person’s experience with a product depends on far more than the code that drives its operation. Support and communication can be crucial elements, particularly when you're introducing something new or changing the way something works after a long period of consistent behavior.
The help offered within a product may require adjustment, staff may need to be trained, and communication of those changes may be necessary. Fail to accompany changes or new features with accurate and reliable support mechanisms, and you risk confusing your customers.
The balancing act
So, given all that, how do you balance the need for speed against customer needs? Follow these basic principles.
Make small changes.
Focus on incremental adjustments, rather than rapid delivery. Smaller, more targeted changes typically carry less risk of error. Small changes in operation, look, and feel are likely to be less noticeable, and people who value familiarity can more easily accommodate these.
Other factors to consider here include:
- Upgrade files should be smaller and installation times shorter so that the process is less disruptive.
- Instructions to communicate the nature of the change should be simple.
Not only does this approach allow you to make changes more frequently, but emphasizing size over speed is also healthier for overall quality.
Give the customer control whenever possible.
Customers need to have a sense of control over the changes made to their applications, as well as the timing of when they occur. A feeling of control can result from:
- Providing opportunities for people to react to features and other changes they like or don't like
- Allowing simple configuration options to toggle changes on and off where possible, or in some cases retaining existing behavior or appearance with an option to switch changes on (rather than the other way around)
- Allowing customers to choose when to install an upgrade, and providing clear information on the implications (such as the file size, likely duration of an installation, and need for restarts)
Think about the customer first.
Empathy for your customers, colleagues, or anyone else using your product can go a long way. You can do this by:
- Considering accessibility needs for each change you make and factoring in time to test for potential accessibility problems
- Offering opportunities to learn about changes and how to enable or disable them
- Keeping all support channels—documentation, support staff, forums, and communities—well informed about what has changed but also why it has changed
- Explaining why you're not able to offer choice or control (e.g., an urgent security patch is required)
Continuous delivery does not mean losing sight of the people your software is intended to serve. As you adjust your products, take time to think about your customers' different needs and desires. After all, it's their product too. Quality at speed still means meeting people’s needs.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
