5 ms·

TL;DR: They fired the QA team to save money. Then they made the engineers do the QA work for no extra pay.

by Apreche 11y ago

loceng 11y ago
Well, that takes away from the other work than can do - and may incentivize them to more thoroughly check their work as they go. It could be a fairly big improvement to efficiency.
acaloiar 11y ago
Your snark gave me a good laugh.
cpncrunch 11y ago
I think that is a slightly harsh assessment. They forced the engineers to stop shipping shoddy code, so the QA team wasn't necessary in their opinion. However I think there is probably a middle ground where your engineers deliver quality code and you also have a QA team to increase that quality even further.
- jonknee 11y ago
  A failing company cutting QA teams is nothing but a desperate attempt to save money. Yahoo's margins are falling and it's easier to fire people than it is to raise revenue.
- mbesto 11y ago
  > so the QA team wasn't necessary in their opinion. I don't know of any large, complex systems where QA is not necessary. Technology is only fallible because humans are.
  - loco5niner 11y ago
    Note he didn't say "QA is not necessary". He did say "the QA team wasn't necessary". His statement seems to assume that _someone_ is still doing QA.
austenallred 11y ago
I mean, they have a salary, so unless the engineers are required to stay extra hours to do the QA it makes no difference to them.
- jonknee 11y ago
  They might as well take out the trash and clean the floors on their way out. Vertically integrated!
  - ftio 11y ago
    Definitely. Writing software : writing software to test software as writing software : cleaning the floors.
    - pc86 11y ago
      Clearly you've forgotten that doing anything one doesn't want to do, even if it's still software and absolutely part of their job, is "being forced to do it for no extra pay."
  - pc86 11y ago
    I have worked in small companies before where there were no janitorial services, so we emptied our trash cans once a week, and took turns taking the larger bags to the dumpster outside. What's the big deal? And that's not a rhetorical question. I truthfully want to know why you think something like that is silly.
    - jonknee 11y ago
      Because Yahoo isn't a small company? They have been losing a lot of engineers and it must be hell to recruit people to join Yahoo, negative press like this is only going to make it worse. As for why I think having Yahoo engineers take over janitorial duties is silly... If you're paying Silicon Valley engineering wages to someone (which they are, no one is going to Yahoo for stock options!) you should make sure they are working on engineering level tasks. It would be a giant waste of resources to have people do tasks they are overqualified for.
president 11y ago
Hit the nail on the head. I worked for a company that did this as one of their last efforts to save money. Then that company went away..
ngoel36 11y ago
It's impossible to ask engineers to do more work in a day - you can only change the work being done and/or the time you give them to do it. My guess is that they'll be asked to do more automated & sanity testing as part of their cycle, and as a result their timelines will be extended. Imho, this is the way engineering teams should be structured anyways.
- shostack 11y ago
  > "It's impossible to ask engineers to do more work in a day - you can only change the work being done and/or the time you give them to do it." False. If engineers are typically working 9-5 or 9-6, and you give them new responsibilities but keep existing deadlines and scope, it in essence has the effect of forcing them to work longer hours to get the work done (or else...).
  - ngoel36 11y ago
    Sure. But that's never sustainable.
    - shostack 11y ago
      Not sure about that. Many companies have successfully creeped up the responsibilities of people while keeping their pay the same. Add a few tasks here and there, tell them that this will look great come their review, but then lead them along. Not saying this is good or that the practice doesn't result in increased turnover, but that doesn't stop companies from doing it with some success.
BinaryIdiot 11y ago
Did you even read the article? Many of the QA teams were disbanded and did other things like development, test automation, etc.
dgacmu 11y ago
How about the right version: They fired the QA team to force the devs to do a better job of designing for testability. When you have to write and plough through your own tests, you integrate tests earlier, and you modularize your code better to support that testing. There's a lot in the early phases of engineering that the initial devs can do that QA cannot. QA is handed a black box; dev gets to change the box. It's a very similar big-picture realization as the move from "system administration" to SREs/devOps. Having a bunch of people throwing #@*( over the wall that other people then have to make work is a poor model for optimizing the big picture. This is a good move. It's Mayer taking another play from the Google playbook and trying to improve the process at Yahoo.
- protomyth 11y ago
  > They fired the QA team to force the devs to do a better job of designing for testability If that is actually true, then they should have fired the Devs and found ones who understand writing correct and testable code. That is a horrible way to treat people.
  - dgacmu 11y ago
    I think we must be misunderstanding each other. Developers are human. (At least, I think we are.) We respond to the incentives and structure of the environment in which we're developing. A culture of "throw crap over the wall to QA" naturally creates an incentive for quickly writing up features, without balancing that with robustness, because finding the problems "is QA's fault". A culture of "the devs are responsible for the quality of their code" produces better code. The way to treat the devs well is to have the QA folks go off and create or bring in easy-to-use automated testing and CI frameworks, to make it easy for the devs to do the right thing. This is not a new observation - it's been happening over the last 10 years. see, for example, http://blogs.forrester.com/mike_gualtieri/11-02-17-want_better_quality_fire_your_qa_team http://blogs.forrester.com/mike_gualtieri/11-02-17-want_bett... or http://product.hubspot.com/blog/the-classic-qa-team-is-obsolete http://product.hubspot.com/blog/the-classic-qa-team-is-obsol... and, while it's from 2007, http://googletesting.blogspot.com/2007/03/difference-between-qa-qc-and-test.html http://googletesting.blogspot.com/2007/03/difference-between...
praneshp 11y ago
Nope, they did not. And no, they didn't Source: I work there.

TL;DR: They fired the QA team to save money. Then they made the engineers do the QA work for no extra pay.

by Apreche 11y ago

TL;DR: They fired the QA team to save money. Then they made the engineers do the QA work for no extra pay.

Well, that takes away from the other work than can do - and may incentivize them to more thoroughly check their work as they go. It could be a fairly big improvement to efficiency.

acaloiar 11y ago

Your snark gave me a good laugh.

cpncrunch 11y ago

I think that is a slightly harsh assessment. They forced the engineers to stop shipping shoddy code, so the QA team wasn't necessary in their opinion. However I think there is probably a middle ground where your engineers deliver quality code and you also have a QA team to increase that quality even further.

jonknee 11y ago
A failing company cutting QA teams is nothing but a desperate attempt to save money. Yahoo's margins are falling and it's easier to fire people than it is to raise revenue.
mbesto 11y ago
> so the QA team wasn't necessary in their opinion. I don't know of any large, complex systems where QA is not necessary. Technology is only fallible because humans are.
- loco5niner 11y ago
  Note he didn't say "QA is not necessary". He did say "the QA team wasn't necessary". His statement seems to assume that _someone_ is still doing QA.

austenallred 11y ago

I mean, they have a salary, so unless the engineers are required to stay extra hours to do the QA it makes no difference to them.

jonknee 11y ago
They might as well take out the trash and clean the floors on their way out. Vertically integrated!
- ftio 11y ago
  Definitely. Writing software : writing software to test software as writing software : cleaning the floors.
  - pc86 11y ago
    Clearly you've forgotten that doing anything one doesn't want to do, even if it's still software and absolutely part of their job, is "being forced to do it for no extra pay."
- pc86 11y ago
  I have worked in small companies before where there were no janitorial services, so we emptied our trash cans once a week, and took turns taking the larger bags to the dumpster outside. What's the big deal? And that's not a rhetorical question. I truthfully want to know why you think something like that is silly.
  - jonknee 11y ago
    Because Yahoo isn't a small company? They have been losing a lot of engineers and it must be hell to recruit people to join Yahoo, negative press like this is only going to make it worse. As for why I think having Yahoo engineers take over janitorial duties is silly... If you're paying Silicon Valley engineering wages to someone (which they are, no one is going to Yahoo for stock options!) you should make sure they are working on engineering level tasks. It would be a giant waste of resources to have people do tasks they are overqualified for.

president 11y ago

Hit the nail on the head. I worked for a company that did this as one of their last efforts to save money. Then that company went away..

ngoel36 11y ago

It's impossible to ask engineers to do more work in a day - you can only change the work being done and/or the time you give them to do it. My guess is that they'll be asked to do more automated & sanity testing as part of their cycle, and as a result their timelines will be extended. Imho, this is the way engineering teams should be structured anyways.

shostack 11y ago
> "It's impossible to ask engineers to do more work in a day - you can only change the work being done and/or the time you give them to do it." False. If engineers are typically working 9-5 or 9-6, and you give them new responsibilities but keep existing deadlines and scope, it in essence has the effect of forcing them to work longer hours to get the work done (or else...).
- ngoel36 11y ago
  Sure. But that's never sustainable.
  - shostack 11y ago
    Not sure about that. Many companies have successfully creeped up the responsibilities of people while keeping their pay the same. Add a few tasks here and there, tell them that this will look great come their review, but then lead them along. Not saying this is good or that the practice doesn't result in increased turnover, but that doesn't stop companies from doing it with some success.

BinaryIdiot 11y ago

Did you even read the article? Many of the QA teams were disbanded and did other things like development, test automation, etc.

dgacmu 11y ago

How about the right version: They fired the QA team to force the devs to do a better job of designing for testability. When you have to write and plough through your own tests, you integrate tests earlier, and you modularize your code better to support that testing. There's a lot in the early phases of engineering that the initial devs can do that QA cannot. QA is handed a black box; dev gets to change the box. It's a very similar big-picture realization as the move from "system administration" to SREs/devOps. Having a bunch of people throwing #@*( over the wall that other people then have to make work is a poor model for optimizing the big picture. This is a good move. It's Mayer taking another play from the Google playbook and trying to improve the process at Yahoo.

protomyth 11y ago
> They fired the QA team to force the devs to do a better job of designing for testability If that is actually true, then they should have fired the Devs and found ones who understand writing correct and testable code. That is a horrible way to treat people.
- dgacmu 11y ago
  I think we must be misunderstanding each other. Developers are human. (At least, I think we are.) We respond to the incentives and structure of the environment in which we're developing. A culture of "throw crap over the wall to QA" naturally creates an incentive for quickly writing up features, without balancing that with robustness, because finding the problems "is QA's fault". A culture of "the devs are responsible for the quality of their code" produces better code. The way to treat the devs well is to have the QA folks go off and create or bring in easy-to-use automated testing and CI frameworks, to make it easy for the devs to do the right thing. This is not a new observation - it's been happening over the last 10 years. see, for example, http://blogs.forrester.com/mike_gualtieri/11-02-17-want_better_quality_fire_your_qa_team http://blogs.forrester.com/mike_gualtieri/11-02-17-want_bett... or http://product.hubspot.com/blog/the-classic-qa-team-is-obsolete http://product.hubspot.com/blog/the-classic-qa-team-is-obsol... and, while it's from 2007, http://googletesting.blogspot.com/2007/03/difference-between-qa-qc-and-test.html http://googletesting.blogspot.com/2007/03/difference-between...

praneshp 11y ago

Nope, they did not. And no, they didn't Source: I work there.