An old-timer developer at my shop says this:

A developer's job is to make QA's jobs boring. A QA's job is to catch developers making themselves look stupid. As a developer, I'm happy that QA is better at the job than the developers.

Playing this game in a way that all can laugh over lunch is good for the culture as well as the business.

>It seems odd to me when those in charge ignore the problems of disbanding QA. But I assume it's because the management may not be incentivized to promote quality software. Instead the incentives are to crank out features.

>That said, maybe the market for the software doesn't punish the software makers for having buggy software. In such a case, ignoring QA work is a rational decision.

I think there are a lot of things that promote cost cutting in software quality:

  1. Consolidation: There's usually 1 big player that everyone uses. When that's the case there is nowhere else to go.

  2. Lock in: Even if there was somewhere to go, once you've committed your business to a software vendor, it's really hard (time + expense) to switch.

  3. Executives get bonuses based on income: The easiest way to juice the numbers is to cut employees and departments. The results of cutting QA won't get noticed by the market for a few years.

  4. Over reliance on automated unit testing by management: I think unit testing is great, but it's really hard to utilize it on user XP. It was never meant to be a replacement to manual QA testing, but an augmentation. Of course refer to #3.

  5. Reduction in autonomous middle management: Executives say cut this and cut that, middle management who actually know the process have little to no say, or won't say because they don't want to lose their jobs.

> There should be a adversarial, yet respectful, relationship between dev and QA where dev tries to get their software released and QA is finding reasons why it shouldn't be released.

The mutual respect aspect is key. If the dynamic isn't right, people end up feeling attacked and it can create a contentious environment. Same goes for code review work.

Fire all your operations people first. The developers can do all their own DevOps. That saves at least half the budget.

Then fire all your QA people, because they just keep getting in the way, and the developers can do all of their own QA anyway.

Then don't be surprised when they fire all the developers because they've got this new "no code" thing. But then who is left to implement the "no code"?

Beautifully articulated. This is exactly what’s going on. Incentives are simply misaligned with expectations. In all likelihood, the market doesn’t reward quality software as much as it rewards robust feature sets.

Not necessarily. In all likelihood, the market punishes bad software quality, but with a longer and more complicated feedback loop.

It is easy to see the increased traction due to building new features. It is difficult to understand the slow, grinding attrition that happens due to bad quality.

Another solution is to incentivise the developers by lowering the barrier between them and their users, and changing the success measures from outputs to outcomes.

> If there's only developers who test their own code then they're not incentivized for finding the ways their code breaks.

It totally depends. In many cases it will come back to the original developer if their code breaks in production. That is a lot of incentive to test as thoroughly as possible before releasing.

Only insofar as ensuring that the software doesn't crash in production, or otherwise cause an event that would cause on-call to be paged. If the customer has a bug, and an issue is opened in the bug tracker, what does the developer care? Forty hours a week is forty hours a week. The developer isn't responsible for delivering business features on-time, and middle management can't be held responsible for delays that are "inevitable" and "outside their control".