5 ms·

This is hilariously hand-wavey of the complexity and strikes at my frustrations between how most IT engineers see the world vs how real-world engineers do. The

by NamTaf 4y ago

This is hilariously hand-wavey of the complexity and strikes at my frustrations between how most IT engineers see the world vs how real-world engineers do. There are parallel tracks within metres of one another. Switching yards have tonnes of them and require precise knowledge of what’s in what. GPS isn’t SIL. Trains operate in cluttered environments with reflection and echo abound. That causes drift above the separation of tracks. There’s way more than “a few” dead spots, and what happens if those repeaters fall over? There’s tonnes of reasons why high tech isn’t used in train safety-critical systems. The fact you suggest an arduino as an appropriate platform for this is frankly absurd and underscores your misunderstanding of the whole issue. Close enough isn’t good enough. Crashing doesn’t just mean you reboot or reload the program and try again. It means people die. Edit to add: A good rule of thumb I’ve learnt after 15 years in the game: if you look at the solution to an engineering problem and then start a sentence with “why don’t they just…”, you probably don’t understand the problem well enough.

olivermuty 4y ago
To be fair, «why don’t they just» has also made a lot of startup founders very wealthy over the last 15 years ;)
- NamTaf 4y ago
  I’ll cop that, though I’m fairly confident in saying it’s the exception that proves the rule, in that those ones end up knowing the problem space so well that they sort of horseshoe around to seeing new insights others miss.
  - bobthepanda 4y ago
    also, even though some startup founders have become very rich questioning the basics with technology, many more have failed.
jen729w 4y ago
> how most IT engineers see the world vs how real-world engineers do Reminds me of… # Programmers: Stop Calling Yourselves Engineers “It undermines a long tradition of designing and building infrastructure in the public interest … The title ‘engineer’ is cheapened by the tech industry.” https://www.theatlantic.com/technology/archive/2015/11/programmers-should-not-call-themselves-engineers/414271/ https://www.theatlantic.com/technology/archive/2015/11/progr...
- smileysteve 4y ago
  But this is a "tech" problem where signals and switches operating by humans are error prone, and the technology to automate those exists. The article is about a tech solution and deployment never able to come (in the U.S.)
- porknubbins 4y ago
  But computer programming is an enormous field and there are types of programming that look very much like engineering- ie using the laws of science for practical applications. I agree a startup putting up a website isn’t engineering, but if building rockets is engineering (which it surely is) then building the software to safely operate those things is engineering too.
  - abofh 4y ago
    In as much as brushing your teeth is dentistry, yes.
naijaboiler 4y ago
IT engineers routinely do that to other fields as well. I'm a doctor and tech guy. The amount of times I have to read the ignorant arrogance of some guy thinking some ML is about to replace doctors... I wish people will just stick to what they know best, and approach other fields with respectful curiosity.
- smileysteve 4y ago
  I do have experience using location beacons where GPS isn't available, along with inferring location from other sensors though...
  - sudhirj 4y ago
    in systems where thousands of lives depend on your design working correctly even in adverse conditions like storms ? Most of us have classifiers to tell if a picture is a hot dog or not a hot dog, but we don’t necessarily tell hospitals we’ve solved the problem of early cancer diagnosis.
- Schroedingersat 4y ago
  > The amount of times I have to read the ignorant arrogance of some guy thinking some ML is about to replace doctors... Don't worry, it will. A bunch of people will die afterwards, but they'll all be poor so noone will care when they look at how much it improved profits.
smileysteve 4y ago
This wasn't a "why don't they just" response though because the article does touch on GPS and the issues it poses. The Arduino comment was not supposed to be taken literally as a production solution. There's a big difference between "why don't they just" and "these problems spelled it in the article seem overstated"
smileysteve 4y ago
Coincidentally, I have worked with localized location beacons deployed to nationwide chains of stores that help you find the aisle the item you're looking for is on.
smileysteve 4y ago
> There’s way more than “a few” dead spots, and what happens if those repeaters fall over? Presumably, given the 2 sets of analog systems currently in place, you fail safe to the inefficient systems in the article, when a vehicle doesn't know it's location.
- robocat 4y ago
  That is even more hilariously hand-wavey, given you just got smoked for that. Fail-safe systems are notoriously hard to design - what is the truth when one system is wrong? How do you detect that a system is giving the wrong answer (737MAX hardware sensor failure, software working exactly as very carefully designed)? Adding complexity decreases reliability unless some very deep voodoo engineering is applied. I think you are thinking linearly, that two systems with a 1% failure rate could be put together to make a system with 0.01% failure rate. Bzzzzzzt, wrong, instead you could easily end up with a system with a 5% failure rate. There are many sources of confounding variables: two systems tend to fail in the same complex corner cases, safety systems tend to have common dependencies (Fukushima tidal wave), and adding complexity to systems adds subtle failure modes. Disclaimer: I would call myself a software engineer, because my definition of engineering is making good compromises. Other “engineering” disciplines very often work on non-safety critical systems, yet they are still called engineers. And these days software underpins most safety critical systems e.g. you depend somewhat that your CAD software or circuit analysis software returns the correct result, even though software usually disclaims all warranties/guarantees. The designers of the space-shuttle made safety compromises, but that was engineering. SpaceX followed a fail-fast approach, and I think software engineers have been innovating and optimising that methodology for many years (not saying it was invented by software engineers). Engineering for safety is an orthogonal skill to engineering discipline. Edit: wrench on your own vehicle safety systems, and you can’t help but notice multiple potential safety faults, often related to usability fails. Mechanical engineers design with unforeseen safety failure modes. Engineering is a spectrum. Making appropriate good compromises is engineering. Ingroup “engineers” versus outgroup “engineers” is miscategorisation and politics: especially considering the root of the word and that we use the word certified when we want a “real” engineer. https://probablydance.com/2022/09/17/finding-the-second-bug-in-glibcs-condition-variable/ https://probablydance.com/2022/09/17/finding-the-second-bug-... is an example of deep software engineering guruness, uncovering heisenbugs in complicated poorly written GNU glibc synchronisation primitives. My considered opinions.
zokier 4y ago
https://en.wikipedia.org/wiki/European_Train_Control_System#GNSS https://en.wikipedia.org/wiki/European_Train_Control_System#...
tazjin 4y ago
> This is hilariously hand-wavey of the complexity and strikes at my frustrations between how most IT engineers see the world vs how real-world engineers do. This has become glaringly obvious after starting to learn how aviation works and working on getting a PPL. If you know about this tech, it's interesting to ask software engineers to invent something like ILS and see what they come up with. There's a tendency to both underestimate what is needed AND overengineer the solution.

by NamTaf 4y ago

olivermuty 4y ago

To be fair, «why don’t they just» has also made a lot of startup founders very wealthy over the last 15 years ;)

NamTaf 4y ago
I’ll cop that, though I’m fairly confident in saying it’s the exception that proves the rule, in that those ones end up knowing the problem space so well that they sort of horseshoe around to seeing new insights others miss.
- bobthepanda 4y ago
  also, even though some startup founders have become very rich questioning the basics with technology, many more have failed.

jen729w 4y ago

> how most IT engineers see the world vs how real-world engineers do Reminds me of… # Programmers: Stop Calling Yourselves Engineers “It undermines a long tradition of designing and building infrastructure in the public interest … The title ‘engineer’ is cheapened by the tech industry.” https://www.theatlantic.com/technology/archive/2015/11/programmers-should-not-call-themselves-engineers/414271/ https://www.theatlantic.com/technology/archive/2015/11/progr...

smileysteve 4y ago
But this is a "tech" problem where signals and switches operating by humans are error prone, and the technology to automate those exists. The article is about a tech solution and deployment never able to come (in the U.S.)
porknubbins 4y ago
But computer programming is an enormous field and there are types of programming that look very much like engineering- ie using the laws of science for practical applications. I agree a startup putting up a website isn’t engineering, but if building rockets is engineering (which it surely is) then building the software to safely operate those things is engineering too.
- abofh 4y ago
  In as much as brushing your teeth is dentistry, yes.

naijaboiler 4y ago

IT engineers routinely do that to other fields as well. I'm a doctor and tech guy. The amount of times I have to read the ignorant arrogance of some guy thinking some ML is about to replace doctors... I wish people will just stick to what they know best, and approach other fields with respectful curiosity.

smileysteve 4y ago
I do have experience using location beacons where GPS isn't available, along with inferring location from other sensors though...
- sudhirj 4y ago
  in systems where thousands of lives depend on your design working correctly even in adverse conditions like storms ? Most of us have classifiers to tell if a picture is a hot dog or not a hot dog, but we don’t necessarily tell hospitals we’ve solved the problem of early cancer diagnosis.
Schroedingersat 4y ago
> The amount of times I have to read the ignorant arrogance of some guy thinking some ML is about to replace doctors... Don't worry, it will. A bunch of people will die afterwards, but they'll all be poor so noone will care when they look at how much it improved profits.

smileysteve 4y ago

This wasn't a "why don't they just" response though because the article does touch on GPS and the issues it poses. The Arduino comment was not supposed to be taken literally as a production solution. There's a big difference between "why don't they just" and "these problems spelled it in the article seem overstated"

smileysteve 4y ago

Coincidentally, I have worked with localized location beacons deployed to nationwide chains of stores that help you find the aisle the item you're looking for is on.

smileysteve 4y ago

> There’s way more than “a few” dead spots, and what happens if those repeaters fall over? Presumably, given the 2 sets of analog systems currently in place, you fail safe to the inefficient systems in the article, when a vehicle doesn't know it's location.

robocat 4y ago
That is even more hilariously hand-wavey, given you just got smoked for that. Fail-safe systems are notoriously hard to design - what is the truth when one system is wrong? How do you detect that a system is giving the wrong answer (737MAX hardware sensor failure, software working exactly as very carefully designed)? Adding complexity decreases reliability unless some very deep voodoo engineering is applied. I think you are thinking linearly, that two systems with a 1% failure rate could be put together to make a system with 0.01% failure rate. Bzzzzzzt, wrong, instead you could easily end up with a system with a 5% failure rate. There are many sources of confounding variables: two systems tend to fail in the same complex corner cases, safety systems tend to have common dependencies (Fukushima tidal wave), and adding complexity to systems adds subtle failure modes. Disclaimer: I would call myself a software engineer, because my definition of engineering is making good compromises. Other “engineering” disciplines very often work on non-safety critical systems, yet they are still called engineers. And these days software underpins most safety critical systems e.g. you depend somewhat that your CAD software or circuit analysis software returns the correct result, even though software usually disclaims all warranties/guarantees. The designers of the space-shuttle made safety compromises, but that was engineering. SpaceX followed a fail-fast approach, and I think software engineers have been innovating and optimising that methodology for many years (not saying it was invented by software engineers). Engineering for safety is an orthogonal skill to engineering discipline. Edit: wrench on your own vehicle safety systems, and you can’t help but notice multiple potential safety faults, often related to usability fails. Mechanical engineers design with unforeseen safety failure modes. Engineering is a spectrum. Making appropriate good compromises is engineering. Ingroup “engineers” versus outgroup “engineers” is miscategorisation and politics: especially considering the root of the word and that we use the word certified when we want a “real” engineer. https://probablydance.com/2022/09/17/finding-the-second-bug-in-glibcs-condition-variable/ https://probablydance.com/2022/09/17/finding-the-second-bug-... is an example of deep software engineering guruness, uncovering heisenbugs in complicated poorly written GNU glibc synchronisation primitives. My considered opinions.

zokier 4y ago

https://en.wikipedia.org/wiki/European_Train_Control_System#GNSS https://en.wikipedia.org/wiki/European_Train_Control_System#...

tazjin 4y ago

> This is hilariously hand-wavey of the complexity and strikes at my frustrations between how most IT engineers see the world vs how real-world engineers do. This has become glaringly obvious after starting to learn how aviation works and working on getting a PPL. If you know about this tech, it's interesting to ask software engineers to invent something like ILS and see what they come up with. There's a tendency to both underestimate what is needed AND overengineer the solution.