Menu Fermer

Speed vs. Quality: Why You Shouldn’t Have to Choose

In software engineering, the tug-of-war between speed and quality has become a familiar story. Organizations push for faster releases, while teams struggle to maintain high standards. But what if we’re asking the wrong question? Instead of choosing between speed or quality, what if we could sustainably achieve both?

This is exactly the question Jit Gosai tackles in his thoughtful posts on Quality Engineering. Drawing from talks like “Speed vs Quality: Can You Have Both?” and quality studies from Testbash UK, he proposes a smarter approach — literally.

The traditional method of dealing with delivery pressure is to simply work harder. Teams stretch their hours, cut corners, skip steps, and hope for the best. Initially, this seems to work. Delivery speeds up. Deadlines are hit. Everyone celebrates.

But this comes at a cost. Technical debt creeps in. Testing is rushed. Bugs emerge. The quality drops, and ironically, the team slows down — now spending more time fixing problems than delivering value.

Jit labels this the « Working Harder Loop » — a cycle where short-term speed is traded for long-term stability. It’s unsustainable and traps teams in reactive firefighting.

Contrast that with the « Working Smarter Loop », where teams focus not on doing more, but on doing better. This means:

  • Running experiments to improve delivery practices
  • Using DORA key metrics to track progress
  • Applying the Theory of Constraints to identify and remove bottlenecks
  • Building team behaviors that support experimentation and learning

By systematically improving their capability to deliver, these teams gain both speed and quality — and maintain them.

To reduce the ambiguity of what « speed » and « quality » actually mean, Jit advocates for using the DORA metrics, which Google has extensively validated:

  • Deployment Frequency and Lead Time for Changes: proxies for speed.
  • Change Failure Rate and Mean Time to Restore (MTTR): proxies for quality.

These metrics give teams a shared language and clear goals. Crucially, they help organizations avoid vanity metrics and focus on what drives true performance.

To move from measurement to improvement, Gosai introduces the Theory of Constraints (ToC) — a structured approach to uncovering what’s slowing you down and fixing it methodically:

  1. Identify the constraint in your process
  2. Exploit it with quick wins
  3. Subordinate surrounding processes to support the constraint
  4. Elevate the constraint with experiments
  5. Repeat — the constraint will shift

This isn’t just theory. It’s deeply practical and works best when teams visualize their development flow — even using playful methods like Tom Wujec’s « how to make toast » workshop to collaboratively model processes.

Still skeptical? Google’s research makes the strongest case yet: code quality isn’t just a nice-to-have — it causally improves developer productivity.

In a 2022 study from Google (Cheng et al., ESEC/FSE), researchers analyzed panel data from over 2,000 engineers. They found that increases in perceived code quality directly led to increases in self-rated productivity, not the other way around.

This debunks the myth that you have to slow down to improve quality. Instead, investing in quality can make your teams faster.

Jit emphasizes that smarter working isn’t just a process shift — it’s a mindset change. Leaders must:

  • Give teams the space to experiment
  • Accept temporary instability in the name of progress
  • Encourage behaviors like psychological safety, learning from failure, and cross-functional collaboration

Without this cultural foundation, even the best tools and metrics won’t lead to lasting change.

It’s time to stop treating speed and quality as trade-offs. The real enemy isn’t slowness or imperfection — it’s inertia. As Jit wisely puts it: “Do not allow inertia to cause a system constraint.”

To go fast and deliver with excellence, teams must evolve how they work — not just how fast they work.

📬 To dive deeper into these ideas, explore Jit Gosai’s full newsletter at qualityeng.substack.com

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *