3 ms·

> They forgot the software equivalent of a line-ending semicolon when they eliminated a single-support bolt for the catwalk accidentally during design review.

> They forgot the software equivalent of a line-ending semicolon when they eliminated a single-support bolt for the catwalk accidentally during design review. Absolutely not. Their original design supported only 60% of the minimum load specified by the Kansas City building code. However, that's not why they changed it. A supplier pointed out that the design was impractical to assemble, and suggested an alternative. The engineers in charge accepted that alternative without doing any calculations about its effect on the load-bearing capacity of the walkways. Had they done so, they would have seen that the new design could support a mere 30% of the minimum load required by the building code. Their engineering process was flawed from start to finish. If I had to make an analogy to software, it would be a company that regularly did development on the production box. Engineering is not about never making mistakes. Forgetting a semi-colon is common, and any software engineering process that depends on people never forgetting something that trivial is fatally flawed. When you make a mistake in vehicle control software, there should be many layers of failsafes to catch it, such as: the compiler, automated unit tests, automated acceptance tests, code review, manual feature testing (with a simulator), manual release testing (with a simulator), integration testing on a vehicle that has been immobilized, integration testing on a closed track, and production environment trials. Keep a few mistakes between yourself and disaster. One mistake is a very slim margin.

djsumdog 8y ago
A better analogy would be promoting a service to production with the unit tests failing (or not having an automated CI process that ran the unit tests ... or not having unit tests). There are different degrees of software engineering. If you work for a company that makes pacemakers, there are very strict software testing requirements. The same goes for the developers of real time avionics systems for air craft, ECUs for cars and autonomous train systems in places like Singapore or London. If you're writing software that tracks inventory and ships out shoes, mistakes aren't life threatening and you might have faster processes to get things into production. If you reuse that software for shipping out medical equipment for people with diabetes or sleep apnea, you could run into life treating problems if the testing process is not updated to match the seriousness of the problem you're trying to solve.
- slavik81 8y ago
  > There are different degrees of software engineering. That's true, but at some point it's no longer engineering. To practice engineering in my jurisdiction, it's required that you hold a professional license and work for a company with a permit to practice. I am a professional software engineer (P.Eng.), but many employers for non-critical software do not have a permit to practice. They have no need for it. I need to file my Continuing Professional Development hours every year. One category of hours is just "practicing engineering". However, if I am working for a company that does not have a permit to practice, it would be quite a problem if I claimed I was practicing engineering. Practically speaking, that means software engineering is just the development of software which could be dangerous (at least where I live). It's distinguished from general software development mostly by the need for rigour.
  - gpvos 8y ago
    Fascinating! Which country is that?
    - ringshall 8y ago
      Given the 'P.Eng', probably Canada.
    - slavik81 8y ago
      Canada. I should also note that anyone can assist an engineer, so it's not like Computer Scientists are cut out of the field. Many disciplines have technicians and other specialists who are just as technically capable as the engineers in their domain (often more so). The lead engineer signs off of on releases, and they're the main person held responsible if there's a safety incident traced back to sloppy work. That was the only real difference between the engineers and non-engineers I worked with. It basically just meant, "the buck stops here."
ThenAsNow 8y ago
> Engineering is not about never making mistakes. Forgetting a semi-colon is common, and any software engineering process that depends on people never forgetting something that trivial is fatally flawed. When you make a mistake in vehicle control software, there should be many layers of failsafes to catch it, such as: the compiler, automated unit tests, automated acceptance tests, code review, manual feature testing (with a simulator), manual release testing (with a simulator), integration testing on a vehicle that has been immobilized, integration testing on a closed track, and production environment trials. > Keep a few mistakes between yourself and disaster. One mistake is a very slim margin. This is all spot-on. In a related vein, I used to despise any mention of "Systems Engineering", and then I worked in the development of complex systems. "Systems Engineering" is really about mindset, tools, and processes to impose coordinated rigor in the engineering of a given system. There is no Theory of Systems Engineering in the same way there are theoretical underpinnings in Mechanical, Civil, Electrical, Aerospace Engineering, etc. Elevating it academically to a fully-fledged field of engineering in the same way as these is the irritating part. However, the likelihood is extremely high that with any large and complex physical system that embodies a strong degree of correctness, good systems engineering practice was integral to its development. I do not think the majority of software development today corresponds to real engineering practice for any rigorous definition of "engineering". In general, it is much closer to the practice of a craft, like fine carpentry or auto body work (c.f., Eric Sink). What you describe, very aptly, with multiple "mistakes between yourself and disaster" and an embrace of rigor, verification, and deliberate effort undertaken to compensate for the lack of inherent rigor in things like our programming languages, is engineering. Writing lots of code does not make one a "software engineer" any more than building a table in my wood shop makes me a mechanical or civil engineer. If you cannot explain how you develop systems where the implementation in code is just the final manifestation of a design, and that you specifically have systems in place to compensate for or screen out implementation flaws (especially the ones your implementation tools cannot eliminate by construction, e.g., many of today's commonplace programming languages) and logical flaws, then you are not practicing software engineering. Our ability to construct large and complicated systems in software today far outstrips our ability to rigorously guarantee that the software satisfies correctness properties. This is fundamentally unlike what systems engineering with traditional physical engineering disciplines can provide. I think what Germany is doing is here is right, and fundamentally different than all the stuff going on in the U.S. with Tesla, Uber, Waymo, etc., that seem to be doing huge amounts of ad-hoc implementation, with no consensus on high-level properties the implementations should verifiably satisfy. The raging debates in the U.S. seem to be about whether or not states should allow systems to be tested on public roads rather than what the provable properties of these systems should be.

djsumdog 8y ago

A better analogy would be promoting a service to production with the unit tests failing (or not having an automated CI process that ran the unit tests ... or not having unit tests). There are different degrees of software engineering. If you work for a company that makes pacemakers, there are very strict software testing requirements. The same goes for the developers of real time avionics systems for air craft, ECUs for cars and autonomous train systems in places like Singapore or London. If you're writing software that tracks inventory and ships out shoes, mistakes aren't life threatening and you might have faster processes to get things into production. If you reuse that software for shipping out medical equipment for people with diabetes or sleep apnea, you could run into life treating problems if the testing process is not updated to match the seriousness of the problem you're trying to solve.

slavik81 8y ago
> There are different degrees of software engineering. That's true, but at some point it's no longer engineering. To practice engineering in my jurisdiction, it's required that you hold a professional license and work for a company with a permit to practice. I am a professional software engineer (P.Eng.), but many employers for non-critical software do not have a permit to practice. They have no need for it. I need to file my Continuing Professional Development hours every year. One category of hours is just "practicing engineering". However, if I am working for a company that does not have a permit to practice, it would be quite a problem if I claimed I was practicing engineering. Practically speaking, that means software engineering is just the development of software which could be dangerous (at least where I live). It's distinguished from general software development mostly by the need for rigour.
- gpvos 8y ago
  Fascinating! Which country is that?
  - ringshall 8y ago
    Given the 'P.Eng', probably Canada.
  - slavik81 8y ago
    Canada. I should also note that anyone can assist an engineer, so it's not like Computer Scientists are cut out of the field. Many disciplines have technicians and other specialists who are just as technically capable as the engineers in their domain (often more so). The lead engineer signs off of on releases, and they're the main person held responsible if there's a safety incident traced back to sloppy work. That was the only real difference between the engineers and non-engineers I worked with. It basically just meant, "the buck stops here."

ThenAsNow 8y ago

> Engineering is not about never making mistakes. Forgetting a semi-colon is common, and any software engineering process that depends on people never forgetting something that trivial is fatally flawed. When you make a mistake in vehicle control software, there should be many layers of failsafes to catch it, such as: the compiler, automated unit tests, automated acceptance tests, code review, manual feature testing (with a simulator), manual release testing (with a simulator), integration testing on a vehicle that has been immobilized, integration testing on a closed track, and production environment trials. > Keep a few mistakes between yourself and disaster. One mistake is a very slim margin. This is all spot-on. In a related vein, I used to despise any mention of "Systems Engineering", and then I worked in the development of complex systems. "Systems Engineering" is really about mindset, tools, and processes to impose coordinated rigor in the engineering of a given system. There is no Theory of Systems Engineering in the same way there are theoretical underpinnings in Mechanical, Civil, Electrical, Aerospace Engineering, etc. Elevating it academically to a fully-fledged field of engineering in the same way as these is the irritating part. However, the likelihood is extremely high that with any large and complex physical system that embodies a strong degree of correctness, good systems engineering practice was integral to its development. I do not think the majority of software development today corresponds to real engineering practice for any rigorous definition of "engineering". In general, it is much closer to the practice of a craft, like fine carpentry or auto body work (c.f., Eric Sink). What you describe, very aptly, with multiple "mistakes between yourself and disaster" and an embrace of rigor, verification, and deliberate effort undertaken to compensate for the lack of inherent rigor in things like our programming languages, is engineering. Writing lots of code does not make one a "software engineer" any more than building a table in my wood shop makes me a mechanical or civil engineer. If you cannot explain how you develop systems where the implementation in code is just the final manifestation of a design, and that you specifically have systems in place to compensate for or screen out implementation flaws (especially the ones your implementation tools cannot eliminate by construction, e.g., many of today's commonplace programming languages) and logical flaws, then you are not practicing software engineering. Our ability to construct large and complicated systems in software today far outstrips our ability to rigorously guarantee that the software satisfies correctness properties. This is fundamentally unlike what systems engineering with traditional physical engineering disciplines can provide. I think what Germany is doing is here is right, and fundamentally different than all the stuff going on in the U.S. with Tesla, Uber, Waymo, etc., that seem to be doing huge amounts of ad-hoc implementation, with no consensus on high-level properties the implementations should verifiably satisfy. The raging debates in the U.S. seem to be about whether or not states should allow systems to be tested on public roads rather than what the provable properties of these systems should be.