Whenever people talk about unionizing or professionalizing software development, I think things of this. Even if it ridiculous for both sides, it is indicative of a group of workers, and an employer, who have decided exactly what their job is (and is not), and what the rules and training pertaining to that job are.

Contrast with software development, which is a free-for-all - mainly for good, but the complete absence of standards or authorities doesn't always seem like a good thing. Just occasionally I find myself thinking that some baseline standards for, say, source control or testing would do everyone a world of good.

There would never be a union so long as fully-qualified software engineers are in-demand - even the deluge of web-designers from the dot-com boom (and today's coding-camp graduates) haven't seen a rise in poor working conditions or unemployment because of the over-supply of labor.

I do advocate some kind of professional certification or charter status for software-engineers involved in safety-critical systems - like how a certified civil engineer needs to sign-off on bridge and building designs - but that's largely for the public's benefit, not solely their own.

There's a reason you see more older (and expensive) aircraft mechanics working on the latest greatest tech, as opposed to older developers.

What do you suspect those reasons may be? Also, what would you describe as latest greatest tech in the context of aerospace industry?

Not gp, but in the context of this thread, the answer is obvious: Unions.

Until we come to a mature understanding of the place that unions have in our working economy, I hope we never see this kind of bureaucracy form in our profession.

When I worked at MSFT as a developer in the early 2000s, we had dedicated test developers who wrote tests. You wrote your code and checked it in after a code review and as long as it passed the integration tests, the test developers wrote their (what would now be called) unit tests and checked them in to make sure someone else didn't break your code.

I think writing your own tests gained favor in the early/mid-2000s with the "extreme programming" and TDD movements (https://en.wikipedia.org/wiki/Test-driven_development)

What are "union rules"? Each union is free to bargain their demands collectively with the employer. If your members think such a rule is stupid, they won't demand it. But your lack of knowledge and disdain of unions is noted.

Yes, this is exactly how we QA in fields where software errors can cost lives.

From a personal perspective, I find that trying to design tests as the developer of the code to be tested is fundamentally difficult -- I have embedded assumptions around the functionality of the code that make it cognitively difficult to fully envision complex failure scenarios. Some of the best test producers I've worked with have had no development background at all.

It's horrendously redundant and wouldn't be applicable to most software, but it does work well; when bugs are picked up by the third or fourth layer of testers, which happens from time to time.

Is this based on seniority, as in the new guys have to write the tests? That way you would at least have some experience with how to code in an easily testable fashion.