The pace and expectations in software development have drastically escalated in recent times. Teams previously mapped out delivery cycles for most software products several months in advance. The Waterfall methodology was the prevalent approach for developing software, and countless organizations widely adopted it throughout different industries. For instance, development for the Microsoft Windows operating system took years before being shipped to the market. Even the incremental updates in the form of service packs took years to release.

In today's fast-paced landscape, any organization that spends months or years shipping out new features to its customers will get left in the dust. The methods for building and deploying software have shifted dramatically, and most companies have adopted rapid development cycles to remain relevant and competitive. Returning to the example mentioned above, Microsoft turned to rolling updates in recent versions of Windows instead of waiting multiple years to ship new functionality. This move allows the company to push out regular and frequent changes instead of making consumers wait years.

These accelerated cycles for building and shipping as quickly and frequently as possible are great for consumers, who get the latest and greatest for their software without the long waits between major versions of an application. However, the pressure on the teams developing the product can lead to them taking shortcuts and cutting corners. In many cases, sacrificing quality and stability caused by these high demands results in buggy products that customers don't want to use.

Startups and small companies are the most susceptible to the burdens and troubles of shipping fast. It's a necessary evil in that environment. When you're in a small team working hard to put out something new and innovative into the world, you need frequent iterations of your product to mold and shape it into something that will keep your business alive. Typically, that means emphasizing rapid release cycles more, leaving less of a startup's minimal time and resources for testing. Larger companies usually have more time and money to spend on quality but at the expense of extended development and deployment cycles.

Most organizations think they can skate by with either speed or quality, but the strategy will only work in the short term. The speedy shipping cycles for startups help them iterate and fix bugs faster, but over time, all of those shortcuts add up to massive technical debt that makes development slower and more challenging. Larger organizations will have processes in place to deliver stable software, but a glacial shipping pace will allow the competition to surpass them. Software teams need both speed and quality to survive the high demands of customers in the modern age of software.

The Importance of Speed in Software Development

As already noted in this article, speed is of the essence when it comes to maintaining a long-term business plan for software development. The competition for the shrinking attention of consumers is fierce, and for many organizations, it's no longer acceptable to work at a slower pace to get things right. Companies that fail to work and adapt rapidly will inevitably face challenges down the road. Outdated features in an application can lead to customers bailing and looking for what they want elsewhere, which leads to a loss of consumers and market share, which inevitably ends in failure.

Throughout the years, we've seen countless organizations fail due to their inability or disinterest to keep up with technological advances. For example, in the 90s and early 2000s, Nokia was synonymous with mobile phones. But when Apple introduced the iPhone and Google followed with Android, Nokia chose to cling to its existing software platform instead of getting on board with the more modern and advanced mobile ecosystems consumers wanted. The company rapidly lost over 90% of its market value over the next few years, never regaining its status in that market segment.

However, going fast also carries some risks. One of the more dangerous risks of going too fast is spending months or years building something people don't want. Most startups don't survive because their founders can't find the product-market fit to make their software sustainable. Large organizations also have this problem with new products, like Google. The company pushed out Google Glass in 2013, and while many had a fascination with the device, Google failed to figure out why most people would want to spend $1,500 for the product. The company also didn't take the time to think about privacy and safety concerns in its attempt to get to market quickly. As a result, the product ended up as one of Google's highest-profile flops.

The most obvious risk in rushing to market is that it can lead to products getting released without being fully complete. We see it all the time in software and hardware products. For instance, Apple released Apple Maps in 2012 as an attempt to replace Google's mapping services on their devices. However, the product was clearly not ready for prime time, with tons of errors, inaccurate directions, and missing data. In another example, Microsoft also faced heavy criticism for their launch of Windows Vista, which was slow and unstable, and many developers on the project blamed the rushed release schedule for these issues.

To combat these problems, organizations often need to pause for a moment and look at how they're addressing the quality of their products.

The Need for Quality in Software Development

Quality in software is a highly desired yet often neglected segment of the software development lifecycle. Everyone wants the highest possible quality in their products, but few place the proper amount of emphasis needed for it in the name of speed. Many development teams pay a lot of lip service to testing and QA processes without taking any action. In some teams, especially in the era of "break things fast", quality is sometimes viewed as the direct opposite of rapid development, but that couldn't be far from the truth.

Some examples mentioned earlier in this article discuss why quality is essential. When you expedite the development of an application and ignore quality issues in order to get things out the door quicker, the problems that come up will inevitably lead to system failures, security breaches, and a lack of trust in your brand. We've seen plenty of organizations on the news that ran into difficulties and crises due to poor quality, from startups to tech giants.

Focusing on quality, however, isn't the silver bullet solution to these issues. In fact, focusing too much on one area can have a detrimental effect on the development process. Besides causing release schedules to slow down and extend far beyond their deadlines, it also risks deteriorating the team's morale due to stringent QA policies. I worked at a startup that made the QA team the gatekeeper of whether we could release updates to a web application. Their standards were relatively high, and minor issues completely halted deployment. The back and forth between development and QA grew tense with each schedule slippage. Neither developers nor testers stayed long at the company, and the turnover was one reason why that startup doesn't exist today.

In some industries, quality is an absolute necessity. You wouldn't want to use a pacemaker that a lab hasn't thoroughly tested or Internet banking that a security specialist hasn't audited. But in the software industry, the reality is that most developers are building web or mobile applications that don't have any enormous ramifications if the product isn't working at all times as expected. You might risk losing customers for the occasional minor bug or usability issue, but we rarely encounter problems in software that create adverse real-world effects. Most times, they're minor annoyances that don't cause customers to leave in droves.

As software developers and testers, we don't want to slow down too much or put buggy software into the world. What we need is to learn how to balance speed and quality properly.

Balancing Speed and Quality in Software Development

Going too fast with development and testing will lead to quality issues, but focusing too much on quality can slow down your entire process. The trick is to find the right amount of each for where the project stands at the time. Of course, getting to a point where we can safely test and deploy applications in rapid iterations is much easier said than done. However, it's doable with time and effort.

Here are five tactics that you can put into practice in your organization that will help bring you and your team closer to the right balance for speed and quality across all your applications.

1) Automated testing

Most software teams have testing processes in place, but often, they treat those processes as a secondary task that doesn't have much importance compared to building features and patching bugs. Even in 2023, many teams I've worked with do mostly manual testing just before deployments—a slow, tedious, and error-prone process that causes problems to slip unnoticed. Automating these repetitive tasks gives them a significant boost by eliminating them and catching regressions quicker. Test automation isn't a replacement for manual testing, but it definitely helps speed and quality in an application.

While automated testing helps developers and testers complete their tasks quicker, it can become an obstacle if teams don't pay close attention to it throughout the entire product lifecycle. I've seen teams boast that they have thousands of automated test cases, but upon closer inspection, the automation isn't helping them as much as they think. The team likely has huge gaps in coverage, or they're not testing high business value segments of the application. The test suite also takes hours to run and fails frequently due to flakiness, leading them to spend more time fixing the test suite and taking precious time away from other work. The key is to ensure that automated testing keeps speed and quality balanced well enough to help the team deliver quickly and address issues as soon as possible when that balance is tipping over to one side.

2) Continuous Integration/Continuous Deployment

Automated tests for your applications are nice, but if you or your team aren't running those tests frequently, you're wasting time building them. My experience working with hundreds of developers and testers throughout my career shows that very few run their application's automated test suites locally. A continuous integration environment is crucial for any organization that wants to feel confident in delivering its products quickly. A well-built CI system will run your automated tests as often and early as possible to catch potential problems when they're easier and cheaper to fix.

After setting up a continuous integration environment to automate your testing, the next step is to look into continuous deployment to automate your software releases. "Continuous deployment" often refers to deploying an application automatically when any new change lands in your code repository. This strategy is not for everybody, as it requires significant time, effort, and trust to accomplish safely. But teams that employ this methodology build the high quality needed to deploy at any time into their processes, yielding colossal advantages over their competitors. If a team isn't willing to automate their deployments for any reason, they should at least have processes to improve their deployment processes, as it will force a good balance of speed and quality.

3) Feature flags

Feature flags or toggles are a software development tactic that allows teams to set behaviors that can be turned on or off without changing the underlying code. Typically, developers employ this technique to build and release functionality they don't want to make widely available until they can further develop and test in different environments. This way, the team can incrementally release features at a small scale and test them in production without system disruptions.

Feature flags are an excellent way to balance speed and quality in an application since they allow teams to implement and test out new features internally or with a segment of their customers before releasing them into the wild. Testers can have an interface where they can safely toggle different segments of the codebase without developer intervention. The drawback is that too many flags can cause clutter in the codebase and potential confusion about the functionality behind a flag. When used reasonably, however, this approach allows teams to gather feedback, mitigate risks, and address issues quickly while increasing the confidence to deploy a high-quality solution.

4) Canary deployments

Many organizations typically release new features and functionality to all their users simultaneously. While this allows teams to deploy quicker, it can sacrifice quality, especially with teams that don't have many automated tests or implemented continuous integration into their workflow. Even with those systems in place, there's a risk that something will go wrong due to differences between the development, testing, and deployment phases. It's not uncommon for developers to have an application running perfectly fine on their computer or for testers to not find problems in a testing environment only to have the application blow up in production due to a minor difference.

Canary deployments help reduce that risk by gradually rolling out deployments of an application to a subset of users before making it available to everyone. This process allows teams to monitor real-world usage of the new functionality and collect data to determine the safety of the changes. These deployments are slightly similar to feature flags but work at the application level since traffic gets split between the old and new versions of the application. Once everything looks good, the team can redirect everyone to the latest version of the app and remove the previous version. Canary deployments require some upfront work with monitoring and observability systems to track system behavior after deployments. It might also seem that these deployments can slow teams down since they have to wait before fully deploying any changes. However, the effort and time needed to ensure quality eventually leads to improvements in speed down the road.

5) Collaboration between teams

When it comes to balancing quality and speed in the development process, not everything requires a technical solution. The need for a collaborative culture across all the teams involved in the software development lifecycle—developers, QA, and ops—is pivotal for any organization that wants rapid and safe releases of their products. The interconnection between these groups will increase both speed and quality by eliminating obstacles and potential miscommunications while creating a smooth and efficient workflow from start to finish. Automated testing, CI/CD, feature flags, or canary deployments won't matter if all the teams involved in the product aren't on the same page.

When teams collaborate closely together, they can ensure everyone's working on the right thing and come up with better solutions to issues than if they worked in silos. For example, testers help developers by identifying potential weak spots and edge cases that they didn't consider during development, and ops teams can make setting up testing environments for testers more effortless. These collaborative efforts inevitably lead to an improved product because they bring different perspectives and expertise to the table. When everyone works together, they can accomplish more than the sum of what each person can do individually.

Conclusion

Teams can strive towards achieving a good balance of speed and quality by trying some or all of the ideas discussed in this article. Your organization can begin taking small steps towards improving automated testing and implementing continuous integration. Once you start noticing development and QA getting through their work faster with fewer issues, the team can introduce feature flags and canary deploys to assist with smoother and more efficient releases. Even if you don't implement most of these tactics, tight collaboration across all groups will become the most vital component throughout the process. Without solid cooperation, you won't get very far.

Finding the proper balance between working fast and ensuring a high-quality standard for your products isn't easy. It takes a lot of effort and coordination across the organization, from development to testing and beyond. Don't expect changes to happen immediately when you work towards achieving this balance. Teams must understand that it's a slow process and that it's okay if it takes time to begin seeing results. Knowing that progress won't happen overnight is the first step towards improving things. By making the effort to use the strategies mentioned here, you'll get closer to finding the perfect spot for speed and quality.

This article was originally published on my website.

Need guidance to help your team reach the perfect balance of speed and quality while building your applications?

With over 19 years of experience working as a software engineer and tester, I can help you and your organization implement the processes and tools you need to ship your products faster with fewer issues. I have hands-on expertise with each of the tactics discussed in this article while working with dozens of companies across the globe. Send me a message, and let's start a conversation about how you can go from slow development cycles and buggy releases to rapidly deploying your applications with confidence.