People often complain that there is no "science" behind writing software, so therefore it is not an engineering discipline. Articles like this one do a good job showing that the other disciplines aren't nearly as cut and dry as software engineers often think.
Mechanical and civil engineers can lean on equations to make sure that the part will handle expected loads - but that is just step 1 of many. It's effectively the equivalent of "will it compile". After that step are many open questions around maintainability, reliability, costs, etc that have even more unknowns than the average software project. Engineering is an art based in science, no matter what the discipline.
Software in real time embedded systems is highly engineered from my perspective.
Closing on the Toyota recall is very interesting, as it highlights the importance and complexity in engineering real time embedded systems.
- Cosmic radiation could cause a bit-flip resulting in a sudden acceleration event. Even though NASA and NHTSA could not find or demonstrate a problem with fly-by-wire, the issue was identified through expert analysis of the source code, which found that it did not follow best practices either. [0]
It also sheds light on the manufacturer's unpopular approach to these issues.
- The sticking accelerator issue discussed in the article only resulted in 3 complaints to Toyota in 2009 [1]
- Toyota sells 10 million cars a year. We can easily estimate that 50 million are on the road, placing this at or above Six Sigma reliability (3.4 dpmo)
Ultimately braking could safely override a stuck accelerator, still stopping in a safe distance in the most tests [1]
One could argue that the recall was more due to the PR backlash than any degrading part.
And then once you "compile" the drawing into a manufactured part, each output is unique since we can't yet assemble them by placing atoms. And you have to test a slew of them to make sure the variation in structural properties is acceptable. The manufacturing isn't 100% automated for many complex parts, so occasionally a machinist forgets to bevel a hole edge. Inspection dept somehow missed this (they pull 1 of 5 parts from the line and take key measurements) and so it showed up in testing as a drastically reduced part life. And you spent two weeks setting up and running a fatigue test on a part that was improperly made, which now must be repeated (true story).
Just wondering, would computer vision inspection systems fit in to the work flow listed above?
I had a friend that worked for an electronics test equipment manufacture, some of the systems they had were pretty awesome. If a component were off center by something like 1/1000 of a meter the visual inspection system would flag a board for review. The sped that it could find defects was amazing. No human could hope to keep up, so every part on the line could be inspected.
That is definitely in use on many assembly lines in the world today. I saw a camera system that was used to ensure that diabetic needles had the proper cut on the end. It processed thousands of needles an hour.
However, there is always the question of ROI for these types of systems. For many consumer goods it's usually cheaper to just replace broken items than to QA everything to that extent. Thats not allowable on medical devices, airplanes, cars, etc.
"There is science available for writing software, it just gets ignored a lot."
Another important point is software engineering is a baby among the other disciplines. So in its first half century we've had a continuous stream of pitch men selling the new silver bullet that will fix everything, forgotten in a couple years of course. Oh but that NEW scam, its the real thing, this time, yup.
Compare to civil engineering, where the Romans were making great big piles of dirt 2000 years ago. Maybe not as well as we can or as fast as we can, but institutional experience does pile up.
Something to think about as a hard sci fi setting or similar, is a couple centuries in the future, being a programmer will be about as sexy as designing municipal sewer piping, and about as much room for creativity. So we should enjoy the fun while we can.
The biggest part of creating quality products is, as shown in this article, systemically controlling for variation more than the creation itself. Achieving that is all about understanding the sciences of not only engineering, but statistics, systems theory, psychology, and epistemology.
Quality is systemically controlling for variation. Repeat it, know it, love it. Even software benefits immensely from a systems view.
Also, paying more attention to the casual nature of everyday SNAFUs in other people's products and software helps putting things in perspective.
Yes, that production bug may seem like the end of the world for you, but the vast majority of users probably won't even think of it.
Case in point: the time display on the train I commuted with today was off by an hour (DST I presume?) -- plus it had the date as "Oct 1st 2034". I'm not even sure anybody else noticed.
Comments
People often complain that there is no "science" behind writing software, so therefore it is not an engineering discipline. Articles like this one do a good job showing that the other disciplines aren't nearly as cut and dry as software engineers often think.
Mechanical and civil engineers can lean on equations to make sure that the part will handle expected loads - but that is just step 1 of many. It's effectively the equivalent of "will it compile". After that step are many open questions around maintainability, reliability, costs, etc that have even more unknowns than the average software project. Engineering is an art based in science, no matter what the discipline.
Software in real time embedded systems is highly engineered from my perspective.
Closing on the Toyota recall is very interesting, as it highlights the importance and complexity in engineering real time embedded systems.
- Cosmic radiation could cause a bit-flip resulting in a sudden acceleration event. Even though NASA and NHTSA could not find or demonstrate a problem with fly-by-wire, the issue was identified through expert analysis of the source code, which found that it did not follow best practices either. [0]
It also sheds light on the manufacturer's unpopular approach to these issues.
- The sticking accelerator issue discussed in the article only resulted in 3 complaints to Toyota in 2009 [1]
- Toyota sells 10 million cars a year. We can easily estimate that 50 million are on the road, placing this at or above Six Sigma reliability (3.4 dpmo)
Ultimately braking could safely override a stuck accelerator, still stopping in a safe distance in the most tests [1]
One could argue that the recall was more due to the PR backlash than any degrading part.
[0] http://www.sddt.com/Commentary/article.cfm?SourceCode=201311...
[1] http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_...
And then once you "compile" the drawing into a manufactured part, each output is unique since we can't yet assemble them by placing atoms. And you have to test a slew of them to make sure the variation in structural properties is acceptable. The manufacturing isn't 100% automated for many complex parts, so occasionally a machinist forgets to bevel a hole edge. Inspection dept somehow missed this (they pull 1 of 5 parts from the line and take key measurements) and so it showed up in testing as a drastically reduced part life. And you spent two weeks setting up and running a fatigue test on a part that was improperly made, which now must be repeated (true story).
Just wondering, would computer vision inspection systems fit in to the work flow listed above?
I had a friend that worked for an electronics test equipment manufacture, some of the systems they had were pretty awesome. If a component were off center by something like 1/1000 of a meter the visual inspection system would flag a board for review. The sped that it could find defects was amazing. No human could hope to keep up, so every part on the line could be inspected.
That is definitely in use on many assembly lines in the world today. I saw a camera system that was used to ensure that diabetic needles had the proper cut on the end. It processed thousands of needles an hour.
However, there is always the question of ROI for these types of systems. For many consumer goods it's usually cheaper to just replace broken items than to QA everything to that extent. Thats not allowable on medical devices, airplanes, cars, etc.
They're widely used for PCB inspection.
https://www.youtube.com/watch?v=bTij7Juj5qE&feature=youtu.be...
There is science available for writing software, it just gets ignored a lot.
From design by contract, unit testing, integration testing, static analysis, formal proofs, dependent types...
Managers are not willing to invest the required money into development practices that use the techniques above.
Most consumers are not willing to pay for quality and will rather use the software version of 1€ shops quality, if it works most of the time.
Many cowboy coders see software development practices that lead to higher quality as ivory tower advocacy that only gets in the way.
"There is science available for writing software, it just gets ignored a lot."
Another important point is software engineering is a baby among the other disciplines. So in its first half century we've had a continuous stream of pitch men selling the new silver bullet that will fix everything, forgotten in a couple years of course. Oh but that NEW scam, its the real thing, this time, yup.
Compare to civil engineering, where the Romans were making great big piles of dirt 2000 years ago. Maybe not as well as we can or as fast as we can, but institutional experience does pile up.
Something to think about as a hard sci fi setting or similar, is a couple centuries in the future, being a programmer will be about as sexy as designing municipal sewer piping, and about as much room for creativity. So we should enjoy the fun while we can.
The biggest part of creating quality products is, as shown in this article, systemically controlling for variation more than the creation itself. Achieving that is all about understanding the sciences of not only engineering, but statistics, systems theory, psychology, and epistemology.
Quality is systemically controlling for variation. Repeat it, know it, love it. Even software benefits immensely from a systems view.
Deming would be all over this -- right up his alley. http://en.wikipedia.org/wiki/W._Edwards_Deming
Also, paying more attention to the casual nature of everyday SNAFUs in other people's products and software helps putting things in perspective.
Yes, that production bug may seem like the end of the world for you, but the vast majority of users probably won't even think of it.
Case in point: the time display on the train I commuted with today was off by an hour (DST I presume?) -- plus it had the date as "Oct 1st 2034". I'm not even sure anybody else noticed.