Comment by jgust | Hacker News Reader

Comment by jgust | Hacker News Reader

Parent Full thread

I've been saying that software engineering as an industry is in the caveman state of development. The amount of scrutiny that production software gets at _most_ companies is hilariously lacking compared to say, a civil engineering blueprint and there are virtually zero repercussions for failure or negligence. Compare the education & certification required to be called a civil engineer vs. a software engineer and you'll notice that the industry is basically the wild west. You could also argue that computer science isn't yet a "hard science" like mechanical, civil, chemical, etc. engineering are.

I predict that there will be a split in the industry between "software engineer" and "software laborer" where there are specific certifications you need to have before being called an "engineer". "Software engineers" will be held responsible, like civil engineers are, for mistakes that result in accidents. Companies that write safety critical software like auto, air, and space industries where human lives or huge $$$ are on the line will hire engineers, e-commerce companies will continue to hire "code laborers".

Maybe they will even give you a fancy ring to wear?

The software that runs safety-critical flight controls is actually developed nothing like typical ecommerce or social media. It is designed and developed to an engineering standard. You can review DO-178C requirements[1].

Not all software has the same consequences for failure. The highest level is when failure is catastrophic, i.e. "Failure may cause deaths, usually with loss of the airplane." This requires the highest "Level A" assurance level.

Presumably MCAS was not originally evaluated as needing to meet the highest level. If it were, the single AoA input would have immediately disqualified the design right off the bat.

There's some speculation that the delays on the "fix" are because if they have to redevelop the software at a "Level A" standard that means basically a complete reimplementation with full tracability of requirements from design to source code through compilation to executable, with independent verification. That won't happen in a few weeks.

[1] https://en.wikipedia.org/wiki/DO-178C

Do _most_ companies follow DO-178C requirements? Do _most_ software engineers even know what that is?

Companies that develop aircraft control software do. I read your comment as implying that they don't.

> Do _most_ companies follow DO-178C requirements?

No, because most companies aren't developing life-critical software.

I would imagine most companies that are developing life-critical software are familiar with those requirements.

> designed and developed to an engineering standard

Hmmmm. Interesting. Is it legally required to use this standard for these critical softwares?

And are developers legally required to be licensed, in the same way that civil engineers are?

Yes, the FAA must certify the plane as airworthy for it to be legally flown, and the FAA does use this standard's criteria.

It looks like Boeing submitted MCAS at DAL C, using the rationale that it only mutates the stabilizer angle by a few degrees, so it can't be catastrophic. This was a terrible argument for two reasons:

1) It mutates it a few degrees at a time in a non-terminating loop, so it effectively has control authority of the entire stabilizer.

2) Even DAL C would require using more than a single input!

It just depends on the cost of a mistake, you don't need people trained at that level for web dev. I can do data science coding, but I wouldn't trust myself to write Anything where failure could kill someone.

A person should never be trusted for this. Airplanes are more reliable because the processes (and tech) are improving, not the people.

The problem here was that the process got too expensive, so Boeing was pressured into skipping it.

I get your point, and I agree largely, but there is still some element of the people. I wouldn't want someone like myself, who is trained on python and self-taught, to be responsible for any of these components.

> I've been saying that software engineering as an industry is in the caveman state of development.

I once bought a domain called "paleolithic-computing" (neolithic wasn't available, even though I used the stonehenge picture), to use as a blog.

We are indeed in the caveman stage. In fact, in some ways, we seem to have regressed. There is a pressure to release features faster and faster, and everyone knows you can achieve anything in a sprint, right? Then just get 'devops' to deploy.

It helps that most other (or proper) engineering disciplines have been around for far longer. We are not even comparable to egyptians building pyramids, we are still figuring out how to build huts (and rebuilding them every few years with new tech).

Give it time.

This speaks to me. You said this much better than I did. What bugs me about a lot of developers is that they can't see the forest from the trees.

A lot of these serious professions are independent firms that are appointed by a client. I think this can create a different set of incentives compared to working directly as an employee. The firm will be less dependent on the clients success than a direct employee. Your income depends on the quality of your work rather than one single project. And you are more able to see bias in decision making when you are outside of the clients corporate culture. Of course this probably falls down with very large contracts.

On the other hand, being a contractor also means you don't need to be as invested into the maintainability. If it gets too bad you can simply stop working on that project. You don't need to select for solutions for the long term.

Not saying it's strictly that way, just different trade-offs.

Do not conflate software development practices with anything to do with computer science.

Reply on news.ycombinator.com