Hacker News Reader

Comment by tacostakohashi | Hacker News Reader

It is indeed effective, and interesting.

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.

View on HN

> Whenever people talk about unionizing or professionalizing software development, I think things of this.

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.

You get to appreciate the idea more as you get older too.

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

>> 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?

> What do you suspect those reasons may be?

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

I was alluding to unions, and age discrimination. The tech part isn't really interesting in this context.

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.

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)

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.

>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.

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

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.

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

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.

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.

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

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.

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.

Reply on news.ycombinator.com