[kakarot]

Imagine if you weren't allowed to debug or write tests for your own code.

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.

[umeshunni]

Writing tests for your own code is a relatively recent phenomenon.

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)

[mseebach]

Exactly. If union rules had been written down, even in 2005, developers would be forbidden from writing, possibly even running, tests, lest they take away the jobs of the testers. Unit testing would in practice be illegal, never mind (gasp) DevOps.

[bigtimeidiot]

>If union rules had been written down, even in 2005

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.

[flamedoge]

Even running itself. That would actually mean seeing what you wrote. That would be bad. Takes away potential job creation opportunities.

[dogecoinbase]

Imagine if you weren't allowed to debug or write tests for your own code.

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

[kakarot]

I could see the merit in this, would you mind elaborating a little bit?

[dogecoinbase]

My experience is in medical equipment -- not quite the mess that medical devices are, thankfully. The general idea is a combination of redundancy, clean-room methods, and people whose domain expertise is in testing and edge case analysis.

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.

[intrasight]

Actually that's exactly how it is done in highly structured "clean room" software projects. If you fixed the "bug" in your software, then the process team couldn't fix the "bug" in the process that resulted in the bug in the software.

[kakarot]

Could you give me an example of such a project with this kind of restriction?

[marsRoverDev]

Space industry software is siloed in exactly this way. I write code, someone else unit tests it (C), someone else entirely writes integration tests (Java), then someone else writes a final integration test (Java).

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.

[kakarot]

Neat. As long as there is reliable communication throughout the different teams, I guess this kind of thing makes sense for space tech and other highly critical software.

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.