[amlozano]

This point is brought up in the article but I think it is at the real heart of the issue.

QA is almost always seen as a 'cost center' by the business and upper management. I have a hypothesis that you never ought to work in a department that is seen as a 'cost center'. The bonuses, the recognition, and the respect always goes to the money makers. The cost center is the first place to get more work with less hands, get blamed for failures, and ultimately fired when the business needs to slim up. I think the same thing applies to IT.

This spiral is why QA will always be a harder career than just taking similar skills and being a developer. It self reinforces that the best people get fed up and switch out as soon as they can.

[serial_dev]

Even as a developer (mobile app developer) I feel like one has to be careful not to work on "cost center" things.

Accessibility, observability, good logging, testing infrastructure improvements, CI/CD tweaks, stability, better linting and analyzer issues are all important, but you will be rewarded if you ship features fast.

This year I spent too much time on the former because I felt like that's what the team and app needed, because nobody on the team priorized these issues, and I'll be sweating at the end of the year performance reviews.

Now knowing this, I understand why the others didn't want to work on these items, so next year, I'll be wiser, and I'll focus on shipping features that get me the most visibility.

Sorry for the bugs in the app, but I need a job to pay my mortgage.

[tstrimple]

The purpose behind all those things you were pursuing (apart from accessibility) should have been to increase the rate at which the team is able to ship features. If your work on these items over the course of a year haven't demonstrably improved delivery speed, then what value did they actually bring? If they have improved delivery speed and you can show evidence for that, why would you be nervous going into a review?

[hj3939393d]

> demonstrably improved delivery speed

Thinking this can be reduced to a single metric is the blight of modern software (and business in general, I think). Mapping an individual change to improved delivery speed is in the vast majority of cases an impossible task and any decent developer knows this. It's management+ that wants simple easy metrics since they lack the deep understanding required to do their job well. Software development is - despite management's hopes - not line work. It's much more akin to R&D. The line work gets eaten up by AWS.

[tstrimple]

If you can’t prove your contributions are worthwhile, you’re not going to get recognition. People putting out fires get recognition because they are solving visible and urgent problems. If your work reduces the chances of those fires, it should be measurable otherwise what is the point? Do you honestly believe someone who has spent a year “improving processes” but cannot measure the impact of that year of work deserves glowing praise?

And it’s not that managers don’t understand developers and the work they do. It’s that a lot of developers don’t engage at all with what a business actually does. They are working at IKEA while trying to convince management to use the nice dovetail joints instead of that garbage dowel based assembly. Not only do dovetails look better, they are substantially stronger! All very true statements from a craftsman woodworker. But a complete failure to understand the business and how and why it operates as it does and the value they are expected to provide within it.

[carbotaniuman]

It's wild that in this thread we're still falling victim to the McNamara fallacy.

https://en.wikipedia.org/wiki/McNamara_fallacy

[bumby]

I agree with the 'cost center' sentiment, but I'll try to add some nuance from my experience.

1) Some organizations have come to really value what QA/QC brings to the table. From my experience, this seems to be more visible in manufacturing than software. I speculate this is because software is more abstract by its very nature and waste is harder to track.

2) The really good QAs are those who really believe in its mission, rather than those who are looking for the path of least resistance.

Both of those underscore the value lies in organizations and individuals who really buy-in to the QA ethos. There are lots of examples of both who are simply going through the motions.

[dclowd9901]

I work on our frontend platform team and my perf work, CI design and process engineering definitely have a harder time getting recognition and promotions than folks who ship things that translate to dollars in the bank.

I don’t care though. I enjoy making things better and more robust. It makes my soul feel better. I’ll leave fucking things up to the cynics.

[NegativeK]

I've worked in cost center groups almost all my life, and I wouldn't trade it for anything.

I'm fine with bonuses, etc going to other groups. I'm paid well as a tech worker, and many of those jobs would make absolutely miserable -- assuming I turned out to actually be good at them.

[perlgeek]

> I have a hypothesis that you never ought to work in a department that is seen as a 'cost center'

That's why I don't work in an IT department of a traditional business.

[robofanatic]

> QA is almost always seen as a 'cost center' by the business and upper management

Well everything involved in making a product is seen as a cost, that includes the entire development team - QA, Developers, Devops, PM ....

[rubidium]

No. That’s not actually how most orgs break it down. R&D, marketing, sales is “bringing new business” so are profit centers. This means their budget grows with revenue. Manufacturing, QA, IT and service are cost centers so get squeezed year-over-year even if revenue is flat.

[jdlshore]

It depends on the org. In my company, which is a SaaS-like company, all of product and engineering is a cost center, despite creating the product the company sells. It’s just the way they do their accounting.

[itsdrewmiller]

What software companies are not classifying QA as R&D?