In partnership with
The tech industry is continuously scaling and innovating, and with this velocity comes the pressure of maintaining a high level of quality.
Traditionally, it has been believed that engineering teams can either have speed or quality – not both. This mentality isn’t feasible in today’s market. For a business to succeed, both must be achieved.
The content provided in Maintaining speed while minimizing risk takes a look at the methods modern organizations should be putting in place to reduce risk while deploying at a speed that keeps them ahead of the curve.
Episode 1: Minimizing risks in code deployment
When code is pressured to be delivered faster, it goes hand-in-hand with an increased number of stressors and bugs. Every deployment comes with a certain amount of risk – but is this risk always something that should be feared?
In this discussion, our panelists – William Hill (Senior Software Engineer at New Relic), Dawn Parzych (Developer Advocate at LaunchDarkly), and Jackie Balzer (Senior Engineering Manager at Spotify) – and moderator – Stevi Deter (Senior Software Engineer at Providence Digital Innovation Group) – considered how to think about risk and reward when deploying code. They explored the following topics:
- What engineers can do immediately to minimize risks in deployment;
- How to learn from mistakes;
- How to minimize risk without becoming risk-averse;
- Effective tools and exercised that can be used to prepare for failure and have lead to risk minimization;
- Non-technical risks that need to be minimized.
In this article, Mike San Román raises the notion that speed and quality do not have to be opposing forces if engineering leaders focus on exercising ‘a single-gear work mode’. Mike examines the issues that arise from viewing speed and quality as two separate entities, and champions the method of inverting the process to try and solve them. He states, ‘So, instead of creating a task in your backlog to deal with that technical debt, think about how that technical debt is impacting the tasks of your backlog. Use the tasks, bugs, and features that are going to require work on those parts of the codebase to kick off a refactor before you work on the task.’
By identifying the underlying issues that a two-gear way of working creates, and implementing the methods discussed in this article, Mike believes that all engineering leaders can reach a point where speed and quality are no longer at odds.
Matt DeLaney focuses on speed in this article, assessing how organizations can stay ahead of the curve while feeling safe to do so. He looks at the phenomenal statistics regarding ‘elite performers’ in engineering, asking how they are able to ‘deploy 208x more frequently than lower performers’ and ‘recover from incidents 2,604x faster’.
Matt answers with one reason among many: feature management. Diving into this tool, he explains its use of feature flags and the benefits that enable it ‘the ability to deploy features without exposing them to users’. This, ‘paired with the ability to reverse course as soon as an error occurs, give teams the confidence to increase their velocity.’
Matt explains that feature management allows teams stuck in a waterfall cycle to safely move forward to continuous delivery: essential in today’s fast-moving industry.
The theme of uniting speed and quality continues in this article written by Reuben Sutton. Reuben explains that to achieve both, ‘you need to take an approach where you combine curiosity (to find the root causes of issues) with focus (to drive improvements in the systems)’.
Reuben explores why engineering leaders have been led to believe the trade-off between speed and quality for so long, and why, in fact, they are inseparable. Learning from failures, building quality into the process, and alignment on prioritization are all methods Reuben assesses to guide the reader towards achieving unity between the two forces, without giving up essential processes along the way.
A final takeaway
By changing their perspective, and in some cases turning it on its head, engineering leaders can begin to unite the traditionally opposing forces of speed and quality.
As Matt DeLaney says, ‘Those who continue to permit long, drawn-out development cycles will doubtless struggle to compete.’ Achieving high-quality continuous delivery can seem like a daunting task for many leads, but through reflection, preparation, and prioritization, it is possible for engineering teams to keep up with competitors: maintaining a high speed of delivery without compromising the quality of their code.