Skip to main content
Page Tittle
Get Expert Advice on Solving Engineering Challenges
Images
faster-cheaper-better

“Fast, good or cheap, pick two.” This is what the “Iron Triangle,” sometimes called the “Quality Triangle,” points out. In the software world, organizations are challenged with the choice of picking two from the Iron Triangle. But how do they solve this puzzle of picking the combination of best two from the Iron Triangle. The dilemma increases when choosing two of the above characteristics will create an opposing force to the third one.

At fixed costs, choosing quality requires more time to achieve a given task or project. But why should you sacrifice essential features like speed or quality when you can develop the right products at a faster pace?

How do you know if this is a rule or a universal constant?

At Qentelli, we work with different clients to help them solve this equation by using the right strategies and tools. In this blog post, we will explore the conversation of Quality vs. Speed dilemma.

Quality vs. Speed Dilemma

Engineering teams are often challenged with the trade-off between quality and speed. However, in the age of connectivity over geographies, it is not possible to compromise on either of them.  Both, speed and quality are required to maintain and develop your competitiveness in the digital age. In software engineering, having both development speed and delivering quality platforms is a real challenge, but the keys are accessible.

We realize that the “Iron Triangle” has some apparent defects. Indeed, different approaches can be applied at various enterprise levels to overcome this challenge.

DevOps aims to improve the speed and quality of value delivery and cultivate collaboration throughout the value stream by developing and automating a continuous delivery pipeline. Teams often run into Quality versus Speed dilemma. Often teams overlook obvious characteristics of DevOps i.e. Automation. One of the clients we worked with had a legacy POS application and were facing lot of production issues. What happened was, when re-writing their application for a modern tech stack, they did not automate tests for the new application and defect slippage was high into the production environment. There were areas which needed more automation and improvement, read on to know how we overcame the challenges.

The Myth of Quality vs. Speed

Rapid releases are likely to be the principal fact that places a team in front of the speed vs. quality challenge. It may seem of a common-sense that rapid releases may decrease quality until you look at companies like Facebook, Amazon, and Netflix.

These companies with large codebase and infrastructures, deploy code daily, and as end-users, we don’t even feel it. The deployments are so seamless. According to an article by TechBeacon, Netflix engineers deploy code thousands of times per day, while Amazon averages a frequency of a deployment every 11.7 seconds.

These numbers are the counterexample and the evidence that rapid releases don’t mean renouncing the quality. This common belief is a superficial shortcut, a myth flushed out by, not just Amazon or Facebook, but by many other smaller companies. If we look at the common point between these organizations, we will undoubtedly find DevOps and, more concretely, a successful DevOps implementation.

Likewise, code quality impacted by an escalating development velocity is a symptom of inadequate or deficient DevOps implementations.

If you notice that the quality of your product is decreasing when development velocity increases, this can be a symptom of a failed DevOps implementation.

Overcoming the Quality versus Speed dilemma

We have worked with lot of clients who have implemented DevOps but still missing release timelines or facing production issues. DevOps may be interpreted and implemented differently from a company to another, but the CAMS model can decipher it into tangible actions: Culture, automation, measurement, and sharing.

Often, organizations miss the true essence of Automation. We believe that everything in DevOps starts with a cultural transformation; however, automation is also vital for your DevOps journey. We derived similar lessons from teams who missed on the other three aspects of CAMS, i.e. Culture, Measurement and Sharing.

Teams who want to release rapidly without automation usually fall into the trap of choosing between quality and speed. The lack of automation initiatives is one of the crucial reasons why you can’t accumulate both. Automation in DevOps reduces the time required to get a software to deployment. On the other hand, because testing a software in production like environments before releasing should be continuous, any lack of automation will impact your deployment process, therefore testing and feedback on quality.

If you lack processes, you will also fall into the same trap. In DevOps, processes are important, but not as important as the result, because they focus on results. DevOps is nothing without continuous integration (CI) and continuous delivery (CD).

Developers should continually merge their code changes into a shared repository where it’s automatically tested (CI) then automatically built, tested, and packaged (CD). At the edge of this workflow, we end up with packages of software ready to go to production.

Before deploying to production, CI/CD workflows invoke different types of tests like unit testing and integration testing.

Some companies have even continuous deployment processes where code is deployed to production and automatically tested. At this stage, other types of tests are done, like acceptance tests.

With these continuous testing pipelines, we achieve not just a faster time to market, but also a higher ROI and early detection and fixing of bugs. Before running your code in your production infrastructure, the faster you fail, the better it is: Just like Agile, DevOps favors incremental development and failing fast.

At this point, software deliveries are characterized by consistent quality checks at every point of the delivery cycle. This reduces the quality setbacks at the early stages.

The goal is generating production-ready artifacts. Still, there is always a risk when introducing a new software version in production; this is when techniques like Canary Release can help. Using this technique, the new version is rolled out gradually to a tiny group of users before making it widely applicable. Canary Release helps identify defects at an early stage of a production deployment.

Software teams can also benefit from other techniques like A/B testing during which we deploy a feature A to a group of end-users and its alternative feature B to another group. After examining both, the team can judge which of the two features will be widespread.

Without IaC (infrastructure as code) and configuration management, these tasks can be a bottleneck for the whole delivery pipeline. In modern software engineering, infrastructure should be versioned, tested, and released like code. Using IaC technologies, developers can build self-service deployments, testing, and infrastructure.

You Can’t Improve What You Don’t Measure.

All these processes are part of the DevOps continuous improvement. At the end of the cycle, measuring the critical KPI (key performance indicators) for your team is crucial. There are some critical KPIs that you can monitor in your CI/CD pipelines:

  • Lead time, or how fast your code is shipped to production
  • Deployment frequency
  • Speed of deployment
  • Deployment success rate

Choose the critical ones that are in a deep association with your business needs or your organization goals. In an early stage product, if your strategy is to fail-fast and test as often as possible, you will certainly focus on deployment frequency and automated tests failure rate not the usage and traffic reports or service availability and availability KPIs.

We cannot improve what we do not measure. The measurements are what tells us if we’re on the right track. In addition, measuring is an inseparable part of the DevOps feedback loop and continuous improvement process. DevOps is simply obsolete, when measurement and feedback procedures are not implemented.

Conclusion

Engineering teams are often confronted with the trade-off between quality and agility, but experienced DevOps teams know that speed and quality are not mutually exclusive.

Nowadays, it’s unquestionable that sacrificing one to achieve the other, is not a proper resolution.

There are many reasons why some teams choose one over the other, but the lack of some DevOps practices like automation and IaC is the most common cause. Besides, engineering teams must decide the right technology stack to fulfill a balance of speed and quality.

At Qentelli, we have the answer to overcoming quality versus speed dilemmas. We helped companies find and adopt the right solutions without sacrificing neither the quality nor the speed. We follow a DevOps strategy with adequate automation, and we acknowledge quality and excellence from the beginning of the engineering cycle. Write to us about your software engineering dilemma at [email protected]

Authors