The drivers behind software delivery inefficiency

It's hard to believe something when I saw the opposite work in practice. Removing QA makes developers care about production. You can say now they are wasting part of their time doing what QA did but to me it's not wasted time. Incidents went down both times I saw it happen, and stayed down.

Great paper. QA's role in software is underrated.

> Removing QA makes developers care about production

And removing Product Managers makes devs care about the product. Therefore, we should strip away all roles apart from devs..?

These roles exist because the skill set is sufficiently large to justify a dedicated role. If you're a startup, sure - maybe it's better to be lean - but in a larger org, QA folks are worth the investment and can definitely help to spot things that devs may not otherwise catch themselves since they know the product intimately and likely learn of common pitfalls. The few QA folks I've worked with have been worth their weight in gold.

Just to offer a different perspective, my last job removed QA and it was a nightmare. Feature delivery slowed way down and incidents and bugs went way up to the point where we started losing customers.

In theory, I agree with what you're saying, but I think a codebase needs to be in a certain state and a company's leadership needs to be in a certain mindset to make it work. Our codebase was far too large and interconnected for any developer to fully understand all of it because of years of building with unclear boundaries between teams. QA's value wasn't really the testing they did. The value was that we had a dedicated team who's job it was to see the big picture and keep up with the changes 15 different teams were making on the same product. Management wanted the benefits of removing QA without the pain of paying down all the organizational and tech debt that made them valuable.

Again, I agree with your sentiment, but also, I think that most large organizations are not willing to do the necessary work to get a place where QA can be removed.

People are good at different things. Usually they like the things they are good at and vice versa. Different tasks require different mind sets and dev, QA and ops are vastly different in that regard. That is why we have assembly line production in basically every industry except software.

I agree. I saw the same.

Hold up... We saw it at the same place :D

Really depends on what you're having QA folks do.

Writing automated end-to-end tests? Those are very often best done by those writing the software, with assistance from experts who know how to effectively build test infrastructure. I've very rarely seen them done effectively by QA or "test engineering" folks.

Running manual test scripts and torture testing the UI to break it in new and unusual ways? Definitely get dedicated testing / QA folks. It's very easy to be blind to how others might use the software, especially if you wrote it.

Entirely dependent on what you're shipping.

If there is a significant amount of user interaction to test, QA is going to do a better job than devs.

If there's a lot of integration behind the scenes with a ton of edge cases, devs will do a better job.

If you have both (probably), you need both teams to pitch in more than upper management wants to believe and they'll just cut you instead! :D

> Removing QA makes developers care about production

And removing Product Managers makes devs care about the product. Therefore, we should strip away all roles apart from devs..?

Again, I agree with your sentiment, but also, I think that most large organizations are not willing to do the necessary work to get a place where QA can be removed.

Sounds just like every regular software project. That’s why cutting QA is a bad idea for every regular software project. Same goes for product management, unless you are Google and can afford building products people don’t need.

We’ve never had a QA because we are on a tight budget but our PM is acting as a gatekeeper before declaring something as done.

However, there were too many cases that things were delivered as “ready” when they were not. PR review was not enough as everyone were checking diffs from GitHub only.

I implemented an intermediate step where the responsible engineer must post a screenshot or a short video of the ticket before passing to the PM and that alone resolved a lot of issues before they materialized on customers screens, just because you must take the extra effort to work on a proof of work.

We’ve never had a QA because we are on a tight budget but our PM is acting as a gatekeeper before declaring something as done.

However, there were too many cases that things were delivered as “ready” when they were not. PR review was not enough as everyone were checking diffs from GitHub only.

I agree. I saw the same.

Hold up... We saw it at the same place :D

Entirely dependent on what you're shipping.

If there is a significant amount of user interaction to test, QA is going to do a better job than devs.

If there's a lot of integration behind the scenes with a ton of edge cases, devs will do a better job.

If you have both (probably), you need both teams to pitch in more than upper management wants to believe and they'll just cut you instead! :D

Really depends on what you're having QA folks do.

> Writing automated end-to-end tests? Those are very often best done by those writing the software

This so much - but most of the places I've worked at have insisted that manual testers with zero programming experience should build and maintain the test frameworks. Talk about trying to push a square peg into a round hole. Granted some of the testers have embraced it and not done a terrible job but by and large most of the testers have had no idea and done very little.

> Writing automated end-to-end tests? Those are very often best done by those writing the software

Building high-quality test infrastructure often requires more skill than building the software it supports. Some of the most impactful work I've done in staff/principal roles has been test infra.

Yep, very very true. Unfortunately some of the places I've been at more recently have believed that mock servers are the best way to do end to end testing. It was a battle I couldn't win, but no one was willing to see that testing critical UI flows against something that spits back canned JSON could hardly be considered thorough testing.

Several features on this page require Premium Access.

Abstract

''The low hanging fruit'' is not always the one worth cutting. Most of the time, it's the only thing we aim for just because we are too lazy or incapable of reaching out to what's deep and high. ''What is the low hanging fruit?'' is sometimes then a direction of ease rather than impact. When it comes to efficiency and speed of software delivery, I've always witnessed initiatives to cut QA. At the end of the day, QA is a visible stage in the software production process that has its volume and shape – the low hanging fruit so to speak. It's not software creation activity, it involves manual activity, and it has its own cycle of time other than development time. That's why when people think of what to optimize to achieve speed, they think of removing or shrinking QA. However, at the higher trenches of the software development tree more drastic inefficiencies that delay software delivery and kill its productivity. This article examines those inefficiencies for the sake of directing our attention to what we really need to solve to improve delivery speed. It turns out that it's not QA that we should attack the most. If we really want to be efficient, let's leave the ''low hanging fruit'' mentality and aim for what's high and deep – the real drivers behind software delivery inefficiency.

Formats available

You can view the full content in the following formats:

References

[1]

DevOps Research and Assessment (DORA). “DORA’s Software Delivery Performance Metrics.” DORA, https://dora.dev/guides/dorametrics/. Accessed 2 Mar. 2026.

[2]

Cloudflare. “Cloudflare Outage on June 21, 2022.” The Cloudflare Blog, 21 June 2022, https://blog.cloudflare.com/cloudflare-outage-onjune- 21-2022/. Accessed 2 Mar. 2026.

[3]

DevOps Research and Assessment (DORA). “Loosely Coupled Teams.” DORA, https://dora.dev/capabilities/loosely-coupled-teams/. Accessed 2 Mar. 2026.

[4]

Harvey, Nathen, and Derek DeBellis. “Highlights from the 10th DORA Report.” Google Cloud Blog, 23 Oct. 2024, https://cloud.google.com/blog/products/devops-sre/announcing-the- 2024-dora-report. Accessed 2 Mar. 2026.

[5]

Holat, Anl, and Aye Tosun. “Predicting Requirements Volatility: An Industry Case Study.” QuASoQ 2021: 9th International Workshop on Quantitative Approaches to Software Quality, CEUR Workshop Proceedings, vol. 3062, 2021, https://ceur-ws.org/Vol- 3062/Paper08_QuASoQ.pdf. Accessed 2 Mar. 2026.

[6]

Liu, Quess, and Daniel Tsui. “Shifting E2E Testing Left at Uber.” Uber Blog, 2024, https://www.uber.com/blog/shifting-e2e-testing-left/. Accessed 2 Mar. 2026.

[7]

“Code Improvement Practices at Meta.” arXiv, 2025, https://arxiv.org/abs/2504.12517. Accessed 2 Mar. 2026.

[8]

Kuutila, Miikka, Mika Mäntylä, Umar Farooq, and Maëlick Claes. “Time Pressure in Software Engineering: A Systematic Review.” Information and Software Technology, vol. 121, 2020, 106257, https://doi.org/10.1016/j.infsof.2020.106257. Accessed 2 Mar. 2026.

[9]

Obi, Ike, et al. “Identifying Factors Contributing to Bad Days for Software Developers: A Mixed Methods Study.” arXiv, 2024, https://arxiv.org/abs/2410.18379. Accessed 2 Mar. 2026.

[10]

DevOps Research and Assessment (DORA). “Streamlining Change Approval.” DORA, https://dora.dev/capabilities/streamlining-changeapproval/. Accessed 2 Mar. 2026.

[11]

Noda, Abi, et al. “Time Warp: The Gap Between Developers’ Ideal vs. Actual Workweeks in an AI-Driven Era.” Microsoft Research, 2024, https://www.microsoft.com/en-us/research/wpcontent/ uploads/2024/11/Time-Warp-Developer-Productivity- Study.pdf. Accessed 2 Mar. 2026.

[12]

Stripe. The Developer Coefficient. Stripe, 2018, https://stripe.com/files/reports/the-developer-coefficient.pdf. Accessed 2 Mar. 2026.

[13]

Beyer, Betsy, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, editors. “Eliminating Toil.” Site Reliability Engineering: How Google Runs Production Systems, O’Reilly Media, 2016, https://sre.google/sre-book/eliminating-toil/. Accessed 2 Mar. 2026.

[14]

Oehrlich, Eveline. Global SRE Pulse 2022: The State of SRE Adoption, Deployment and Automation. DevOps Institute, 2022, https://insights.devopsinstitute.com/hubfs/Global%20SRE%20Pulse%2 02022.pdf. Accessed 2 Mar. 2026.

[15]

Riggs, Patrick. “Move Faster, Wait Less: Improving Code Review Time at Meta.” Engineering at Meta, 16 Nov. 2022, https://engineering.fb.com/2022/11/16/culture/meta-code-review-timeimproving/. Accessed 2 Mar. 2026.

Hacker Times