I agree, but then they need to be equally well payed... and I don't think it is possible to find a manager willing to pay them as much
In the US, having "Quality" in your title often means that you are in a dead-end job.
In that company, it meant that you were an elite, and that you had considerable power over Engineering.
It also meant that you were a completely anal-retentive S.O.B.
They had spreadsheets with 3,000 rows (each row was a test -usually "monkey" test).
If even one of those rows got a red "X," the whole shooting match would come to a screeching halt, with heads rolling around like foozballs.
It also meant that they double-checked every bug report six ways to Sunday. If they reported a bug, It. Was. A. Bug. No ifs, ands, or buts. If you questioned it, they would get quite huffy; which was not a good thing (see "power," above).
Management kept the QC organization quite separate from Engineering, and they often had an adversarial relationship; which was sometimes encouraged.
This led to engineering departments having some very large testing teams; often outnumbering the engineers. The engineering departments would be penalized for bugs found by the official QC organization, so having large in-house testing teams was worth it.
Their QC doesn't work especially well for software. They would get frowny faces, when I'd suggest automated testing, or process quality best practices.
Quality was always treated separately from construction. I could never quite agree with that, but it also meant that I was "on my own," if I wanted to try using modern quality engineering techniques.
Their [hardware] products are damn good, though. What many companies would consider minor quality issues are treated like Extinction-Level Events, at that company. They've been doing it for 100 years, so it's difficult to argue with them.
Some more details about that behavior are:
In Japan, employees start with a zero score, then for each mistake lose a point. So they will analyze/block anything that could potentially cause a demerit. Obviously that's the polar opposite of "move fast and break things."
Regarding the "3,000 line spreadsheet", yup, that's normal there and part of why their meetings often run to midnight. Gotta check and double-check every row before moving on to the next one. :)
If you want to learn more about these cultural differences, read patio11's excellent posts about working in Japan.
I still have PTSD from that.
Nothing quite like a 14-hour flight, massive jet lag, and an all-day (and all-night) meeting in a packed, cramped, overheated conference room.
- Correct. Before the Doolittle Raid, they weren't cooperating with each other. Things totally changed after Tokyo was bombed.
- One of the reasons for the Pearl Harbor bombing was because the Japanese navy had nothing to do, while the army was engaged in China. But had the navy and army been coordinated, they could have occupied Hawaii.
- before Guadalcanal, the US Navy and Marines weren't very coordinated. After the Marines were abandoned there without half of their equipment and supplies, a protocol was developed that improved communications.
Until today, the Air Force and Army fight over who can operate aircraft on behalf of the Army.
A lot of QA being done is very mechanical and and done by junior staff offshore to keep the cost as low as possible. This causes the value to be low too, for example, the QA team for a F100 company I worked with would meticulously test against specs and file bugs such as "the error message is misaligned on page XYZ". Which was true, but they missed that the error message didn't make any sense at all.
Improved automated testing has the opportunity to free up people to move from Quality Assurance (preventing defects) to being the voice of the user and ensuring quality products. This shift needs a completely different skill set and mindset, but equally it needs organizations to rethink both the cost of software engineering and the value it creates.