At Cypress Conference 2025, I challenged one of the most common assumptions in engineering culture, that better, cleaner code, tests, and tooling by themselves lead to higher-quality software.

High-quality software is fundamentally a social phenomenon. It emerges from how people collaborate, through practices such as pairing, mobbing, and shared ownership. Ultimately to prevent defects before they even have a chance to take root.

What if quality was baked in?

When developers are pairing, defects are significantly reduced due to the broader shared understanding of the system and its intent available at the time the code is written.

Ideally you build together with another engineer or a tester. Together you:

• Discuss and challenge assumptions
• Write tests before implementing the feature
• Review logic in real time

This collaborative dynamic embeds quality early, transforming testing and review from reactive safety nets into proactive design practices. The code, tests, and tools become the outcome of that collaboration rather than its starting points.

What the data tells us

A 14-month industrial study compared solo vs. pair programming[1]:

• Solo development averaged 3.42 defects per module
• Pair programming averaged 1.0 defect per module, representing approximately a 62% reduction in escaped defects.

When you factor in flaky tests, debugging cycles and regressions, the value becomes crystal clear: collaboration helps reduce defects at the source, not merely after the fact.

Too often, teams treat testers like goalkeepers: the last line of defence.

But truly high-performing teams play differently, they intercept the ball before it reaches the goal.

Quality must become everyone’s responsibility, not simply the domain of QA teams or policy checkboxes at the end of the lifecycle.

When we shift from “QA at the end” to “quality built together”, we move from detection to prevention.

Collaborative programming: pairing, mobbing, and shared ownership

Collaborative programming is far more than two people sharing a keyboard.

• Pair programming: Two engineers work together at one workstation, frequently swapping roles between the driver, who actively writes and refactors code while questioning assumptions, and the navigator, who maintains strategic focus, anticipating next steps and guiding the pair toward the desired outcome.
• Ensemble (mob) programming: The entire team collaborates on a single problem at a time, rotating roles and perspectives to maximise shared context and collective intelligence.

These practices foster diversity of thought, shared ownership, and a collective responsibility for quality.

The result:

• Better outcomes
• Cleaner, more maintainable code
• Fewer knowledge silos

Proven outcomes

Teams that pair or mob consistently report:

• Fewer production defects
• Faster onboarding and knowledge transfer
• Cleaner, more maintainable code
• Better documentation practices
• Broader product understanding across disciplines

When the cost of failure is high, you need more brains, not fewer. You cannot depend on solo work and post-hoc QA to deliver resilience.

Quality emerges from how we work together, from shared context, collective decision-making, and continuous collaboration. Especially in complex or regulated environments.

Metrics that matter

Research using DORA metrics and the SPACE framework shows that teams who collaborate closely across QA and development consistently achieve:

Operational outcomes:

• Lower change failure rates
• Shorter mean time to recovery (MTTR)
• More frequent and safer deployments
• Fewer broken pipelines

Human and collaboration outcomes (SPACE):

• Higher satisfaction and engagement
• Better perceived performance
• Greater collaboration efficiency

In other words, collaboration is not just cultural, it’s a measurable performance advantage.

How to get started (without chaos)

My advice for teams new to pairing or mobbing is simple: start small and stay intentional.

1. Identify a pain point. Choose a critical path, a high-defect area, or a flaky test suite.
2. Pair a developer with a tester. Work together to stabilise tests, improve coverage, or fix recurring issues.
3. Use mobbing for complex problems. Bring the whole team together to triage difficult bugs or design decisions.
4. Rotate pairs weekly. Encourage knowledge sharing, prevent silos, and build empathy across disciplines.
5. Measure the impact. Track outcomes — fewer bugs, stronger tests, and higher team morale.

Don’t attempt to transform everything at once. Start where quality hurts most, and build momentum from there.

Testers bring deep expertise in risk, coverage, and system behaviour.

They should never be seen as gatekeepers.

When testers pair with developers:

• Developers learn how to test meaningfully
• Edge cases are identified earlier
• Automated coverage improves in quality, not just quantity

This collaboration frees testers to focus on higher-value activities, exploratory testing, accessibility, chaos engineering, and business-critical flows.

But shifting testing earlier in the lifecycle isn’t enough if teams still operate in silos.

We shouldn’t just shift left, we should shift together.

Collaboration across design, development, and testing is how quality becomes a shared outcome, not merely a phase in the pipeline.

Quality isn’t delegated. It’s co-created.

Reference:

[1] Pair Programming and Software Defects – An Industrial Case Study