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.
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.
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.
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.
So are Q&A people. They are the developer's teams members not their minions.
> 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.
I'm wondering why the presence of a Q&A team would in any way change the professional responsibility of developers to create correct, testable code. If your developers have developed a culture of "throw crap over the wall to QA", then that's on the developers.
> 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.
That is not really the function of QA. Developers need to use proper testing tools on their own, but QA has its own function beyond just testing the code. They also test the assumptions and specification that the "business" ask the developer's to code. They look for bugs that go beyond what a certain set of test criteria instructs. It is also important to supply Q&A with tools to do fast, automated testing. Developer tools are not the function of Q&A.
Q&A has a job to do, and its irresponsible for Developers use them as a substitute for their responsibilities. As an example from other industries, safety is not just the Safety Officer's problem.
// I've been equal years developer and system admin working with good and bad Q&A people
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.
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.
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."
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.
> "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...).
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.
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.
